Why do we have entities in data layer and not in domain layer?

[risayew]

It's just naming convention, but i think according to the clean architecture circle diagram it would be more clear, if the objects defining enterprise business rules in the domain layer would be called entities. Am i right?

[android10]

I guess this is more a matter of taste and I do not like to be tight to strict rules when it comes to naming conventions. For me it is pretty clear when you see a class with the name: User rather than UserEntity :smile:

[risayew]

I think, that it is very important for educational purposes. It can be very time-consuming for newbie, if he/she can't match the theory with the practice.

[Rainer-Lang]

@risayew I'm thinking like you. Everytime someone says "That's clear (for me)" - I'm getting very nervous because I don't know which things are also hidden because of "clearness".

@android10 This project is for explaining CleanArchitecture and for education and also discussion. It could be really better to make the names more clear and speaking. Of course, this is up to you. It's only a suggestion. :)

[risayew]

The naming now isn't only not self-explanatory, but it's confusing too. Because the objects in the data layer are called (*)Entity. So this makes wrong sense about the nature of things.

[Trikke]

Both User and UserEntity in this example are "Entities". It's not because you slap Entity to the back of a class name, that it suddenly becomes an "Entity". How you name it, ultimately depends on you or your team. But you should be aware what an Entity is. (Or a value object, data transfer objects and other things you might come across) So @android10 might call his User class UserCow, it doesn't make it a "Cow", it's still an Entity. Like he said, these are just "rules" applied by himself. You are not forced to copy this example and use it as a rigid example of "this is how it should be done".

Some people name their entities like this :

• Data Layer : UserEntity
• Domain Layer : UserModel
• Presentation Layer : UserViewModel

But then again, it's just naming stuff. And while very important, it does depend on a lot of factors.(yourself, team, spoken languages, the programming language, type of architecture,...)

[risayew]

Thank you for the explanation! I'm agree, that it's just naming. But at the beginning i just wanted to say, that it is not bad, if the naming in theoretical part (on the circle diagram) somehow coincide with the practical implementation in the code. Because it just helps to understand the material faster.

By the way, i have one more naming stuff. Which i believe reflects the nature in a correct way for me(in my opinion). Entities are something from the world of "ideas", and models are from the world of "things". So, an idea we can't neither store nor visualize. On the other side a model can not interchange an entity because an entity is "infinite" in some sense. Therefore Entities should reside in domain and datamodels and viewmodels in data and presentation layer accordingly. In this way the models reflect the entities in a suitable and handy way for the further concrete usage.

[Trikke]

You do make a valid point that for the article/explanation's sake, the article and the example should match up their naming. Maybe that's something @android10 would want to touch up, but this is nothing insurmountable and with a bit of logical thinking you can deduce as much.

About your naming stuff paragraph. A Model is not something that exists as a pattern. It is just a way to name an Entity. Like I could name it UserCow, UserModel, UserPropellor it'll still be an Entity. Entities do not exist solely in one Layer. (The term "Model" does exist in the Model-View-Controller pattern. But here "Model" encompasses an entire part of the architecture, it is not a class)

To use a nice explanation from Stackoverflow

An entity has more semantic significance and is usually tied to a concept (possibly about a real object for example, an Employee or a Student or a Music Album) and is linked to business logic.

Entities are usually used to establish a mapping between an object and to a table in the database. Entities are also known as domain objects. Like I mentioned before, entities will be used in situations where there is business logic and as such it hold information about the system (or part of the system) that it is modeling.

So naming it UserModel doesn't change that it is still an Entity. People just seem to like naming it UserModel because it resides in another Layer. The following naming convention is entirely correct:

• Data Layer : UserEntity
• Domain Layer : UserDomainEntity
• Presentation Layer : UserViewEntity

But these are 3 different kinds of Entities, and mapping should be done between them as not to break the boundaries in the layers.

[risayew]

@Trikke, i see. You go more in the direction of nominalistic approach (https://en.wikipedia.org/wiki/Nominalism, "there is nothing general except names") and my naming has a touch of realistic approach (https://en.wikipedia.org/wiki/Philosophical_realism). Anyway i'm agree, that it's just naming. And the main purpose is to not to break the boundaries. Thank you for the nice discussion!

[Trikke]

You are taking this to a whole new philosophical level :smile: I don't mind what you name your things, i just want to make sure that the concepts behind them are solid. It's not just about breaking boundaries. A Model as a concept doesn't really exists, it's just a way of naming an Entity. I just wanted to make this clear since you were hinting about it being a concept differently from Entity.

But maybe i'm reading too much into that, and this has indeed turned into a philosophical debate. :smile:

[risayew]

@Trikke, i did not mean, that model is a concept differently from entity. But the model reflects an entity. Like a mirror reflects an apple, and we see reflection of the apple, but not the apple itself. )

[android10]

To wrap up, I would say that in this case, each layer uses its own model, so we should call them the way it makes sense for us. Additionally, even Uncle Bob complained about the name Interactor (which for me is pointless), that is why, as you can see in this example, we use UseCase classes.