1
I would like to know the differences between the concepts of Value Objects and entities in object orientation.
NOTE: The question is not whether the use of these concepts are good or not, the doubt is in relation to the conceptual difference of these types of objects.
4
Already I answered about VO.
Entities are all the rest, that is, they are mutable, by reference always, and are usually composed of several other objects, whether Vos or other entities, And something important is that for them to have identity they need an identifier because the object itself has no identity. They exist only because there are other objects to compose it, and a change in some part of its state does not make it another object, it remains the same if the identifier is equal. For all intents and purposes it is the classes that people know in object orientation, but some languages require and in some cases it is necessary that the Vos are classes.
Typical examples are a Customer, a Product, a Invoice. In general the staff not strange much because it is the class that they know, the VO seems somewhat confused because most started learning to program OOP without understanding the fundamental concepts of computing, but they are simple.
One of the criticisms I make for the DDD is that it presupposes a little the technology being used, and one that doesn’t always correspond to reality. It made sense in Java, but for some reason the C# community adopted it, being a language that makes less sense to use DDD. The VO works automatically in C# provided that the person programes properly.
One point that I see as wrong is that people talk about which entity has identity. In fact they don’t, they need an identifier. The object having identity means that its value fully tells what the object is. They even use the right concept, but give a bad name. When you need one value Object specific (the identifier) to give identity to that entity is because the entity as a whole has no identity of its own, needs a ruse to give identity to it.
So in an entity if it has two completely different objects from each other except for the identifier, it’s the same entity. Weird, right? That makes sense for what DDD proposes, and it’s one of the reasons I don’t like.
The part I like about DDD is that having an identifier helps to model in a relational way. Interestingly, the rest doesn’t help. Value objects do not need to be related, they stay within entities in a natural way.
That’s pretty much it. I have read a lot about the subject and each has specific details that vary depending on who is talking, so we can’t say that it has a universal knowledge that goes beyond these basic characteristics.
2
The question is not whether the use of these concepts are good or not, the question is in relation to the conceptual difference of these types of objects.
Difference is the Mutability.
What will be Entity or Value Object depends on the modeling you will do.
If an object within your system’s domain can change state, then you will need a unique identifier for it (ID) and it will be an Entity.
If an object within your domain does not hold state and does not need to exist if it is not related to any other Entity, then consider it as a strong competitor to be a VO.
Ex:
Person is an entity, because even if he changes his name, address or email. He remains the same person!
Name, Address and E-mail are VO because, after being changed, the new ones are important and the old ones are not useful for anything else, they can be discarded because they are no longer being referenced. Changing a VO means replacing with a new overwriting the old.
Some programming languages handle type data String or int as immutable value objects, and if you know how the handling of these types works in these languages, maybe it helps to better understand why this difference in object orientation.
What is the relation with persistence? Aren’t entities the objects that are saved in the bank? It is therefore the presence of the identifier that would correspond to the id of a bank table. The comment made by a user in my question speaks something related to this, could address this question to supplement his answer?
Yeah, it sure is. This is one of the reasons why every entity needs to have an identifier that is usually also used as a table id in relational databases. But think what the ID is useful for in the database? If the entities were immutable we could create a hash of all the values of their fields and that would be their identifier, agree? I think it can help you fix the concept of entity for relational database persistence by taking a look at the difference between relationship Aggregation x Composition.
Browser other questions tagged oop classes terminology objects
You are not signed in. Login or sign up in order to post.
In summary Vos are used to traffic information between application layers, and entities are used for persistence in the database.
– nullptr
Not only for this. I would say that immutability is the main characteristic of a VO unlike the entity that is mutable. In addition, you may have VO that will not be used to move data between layers and you may also have entities even when you are not using any persistence. It is a basic concept of Entity Relationship Model, more specific to Aggregation x Composition. Eric Evans tried to explain in a more objective way to OOP programmers and decided to give a different name, ended up confusing more!!
– phduarte