Value vs Entity objects (Domain Driven Design)

Question

I have just started reading DDD. I am unable to completely grasp the concept of Entity vs Value objects.. Can someone please explain the problems (maintainability, performance.. etc) a system could face when a Value object is designed as a Entity object? Example would be great...

Modigliani

Here I wrote a full (IMO) list of differences between the two: enterprisecraftsmanship.com/2016/01/11/… – Grijalva

@Grijalva I read this article, however I still don't think any of answers below addressed actual ask in OP Can someone please explain the problems (maintainability, performance.. etc) a system could face when a Value object is designed as a Entity object? Example would be great.. which is also am trying hard to understand. I have pluralsight subscription - does any of your course talks about this in detail ? – Turning

@rahulaga_dev Good point. The major issue here is maintainability costs: value objects are much easier to maintain than entities (due to their immutability and lack of identity). I talked about this in my course about anemic domain models: pluralsight.com/courses/refactoring-anemic-domain-model – Grijalva

Answer 1

Reduced to the essential distinction, identity matters for entities, but does not matter for value objects. For example, someone's Name is a value object. A Customer entity might be composed of a customer Name (value object), List<Order> OrderHistory (List of entities), and perhaps a default Address (typically a value object). The Customer Entity would have an ID, and each order would have an ID, but a Name should not; generally, within the object model anyway, the identity of an Address probably does not matter.

Value objects can typically be represented as immutable objects; changing one property of a value object essentially destroys the old object and creates a new one, because you're not as concerned with identity as with content. Properly, the Equals instance method on Name would return "true" as long as the object's properties are identical to the properties of another instance.

However, changing some attribute of an entity like Customer doesn't destroy the customer; a Customer entity is typically mutable. The identity remains the same (at least once the object has been persisted).

You probably create value objects without realizing it; anytime you are representing some aspect of an Entity by creating a fine-grained class, you've got a value object. For example, a class IPAddress, which has some constraints on valid values but is composed of simpler datatypes, would be a value object. An EmailAddress could be a string, or it could be a value object with its own set of behaviors.

It's quite possible that even items that have an identity in your database don't have an identity in your object model. But the simplest case is a composite of some attributes that make sense together. You probably don't want to have Customer.FirstName, Customer.LastName, Customer.MiddleInitial and Customer.Title when you can compose those together as Customer.Name; they'll probably be multiple fields in your database by the time you think about persistence, but your object model doesn't care.

Camber

Where do unshared mutable objects fit in? If in the entire universe there only exists one reference to an object, the object's identity will be irrelevant even if it's mutable. As I see it, a things is an entity if there exists a reference which could be used observe an aspect of state which could change without that reference having been used to change it. If a thing does not attach to the outside world and either it's immutable or only one reference to it exists anywhere in the universe, then the above scenario cannot occur and it's a value. – Corollary

Something like an int[1] may be an unshared mutable value, a sharable immutable value (if none of the things which hold references will ever write to it), or an entity (if two or more references exist, and one of them may be used to write values which may be read using the other). Unfortunately, I know of no language support in Java or .NET for preventing class objects that encapsulate mutable values from accidentally turning into entities. – Corollary

@supercat, If you mean no direct simple support, I would agree, but I do this my eliminating public access to constructors, using only static factories to create new instances, and restricting all access to state through read-only properties (No setters). – Nichani

@CharlesBretana bit late here but I've used this approach (factory methods). However, the confusion for me is where something can be immutable and have an identity, what is that type? For example, a warehouse. You can model warehouse to be a value type (immutable) but it will have a unique identifier such as a warehouse code. This is where the concepts are a bit confusing – Witness

Answer 2

Any object that is collectively defined by all of it attributes is a value object. If any of the attributes change you have a new instance of a value object. This is why value objects are defined as immutable.

If the object is not fully defined by all of its attributes then there are a subset of attributes that make up the identity of the object. The remaining attributes can change without redefining the object. This kind of object cannot be defined at immutable.

A simpler way of making the distinction is to think of value objects as static data that will never change and entities as data that evolves in your application.

Noumenon

Answer 3

Value Types :

• Value types do not exist on his own, depends on Entity types.
• Value Type object belongs to an Entity Type Object.
• The lifespan of a value type instance is bounded by the lifespan of the owning entity instance.
• Three Value types: Basic(primitive datatypes), Composite(Address) and Collection(Map, List, Arrays)

Entities:

• Entity types can exist on his own (Identity)
• An entity has its own life-cycle. It may exist independently of any other entity.
• For example: Person, Organisation, College, Mobile, Home etc.. every object has its own identity

Reganregard

Not related to DDD :( – Peirsen

Answer 4

I don't know if the following is correct, but I would say that in the case of an Address object, we want to use it as a Value Object instead of an Entity because changes to the entity would be reflected on all linked objects (a Person for instance).

Take this case: You are living in your house with some other people. If we would use Entity for Address, I would argue that there would be one unique Address that all Person objects link to. If one person moves out, you want to update his address. If you would update the properties of the Address Entity, all people would have a different address. In the case of a Value Object, we would not be able to edit the Address (since it is immutable) and we would be forced to provide a new Address for that Person.

Does this sound right? I must say that I was/am also still confused about this difference, after reading the DDD book.

Going one step further, how would this be modelled in the database? Would you have all properties of the Address object as columns in the Person table or would you create a separate Address table that would also have a unique identifier? In the latter case, the people living in the same house would each have a different instance of an Address object, but those objects would be the same except for their ID property.

Hoggard

"Take this case: You are living in your house with some other people. If we would use Entity for Address, I would argue that there would be one unique Address that all Person objects link to". I think each of those people has it's own instance of Address, but they just happen to be equal (it's like each of them can have 5 dollar banknote, but that does not mean that it is the same banknote) – Posture

"but that does not mean that it is the same banknote" - I guess this depends on whether one assign or not additional properties to the banknote (e.g. emitted date, physical location in space, etc); otherwise they would be the same. And I guess is the same for software: Address is the same or not depending on the properties we need/want to consider. – Interregnum

Answer 5

address can be entity or value object that depends on the busiess process. address object can be entity in courier service application but address can be value object in some other application. in courier application identity matters for address object

Rabbinism

Answer 6

3 distinction between Entities and Value Objects

• Identifier vs structural equality: Entities have identifier,entities are the same if they have the same identifier. Value Objects on the other hand have structural equality, we consider two value objects equal when all the fields are the same. Value objects cannot have identifier.

• Mutability vs immutability: Value Objects are immutable data structures whereas entities change during their life time.

• Lifespan: Value Objects Should belong to Entities

Comprehensive

Answer 7

In a very simple sentence I can say, we have three types of equality:

• Identifier equality: a class has id filed and two objects are compared with their id field value.
• Reference equality: if a reference to two objects has a same address in memory.
• Structural equality: two objects are equal if all members of them are matched.

Identifier equality refers only to Entity and structural equality refers to Value Object only. In fact Value Objects do not have id and we can use them interchangeably. also value objects must be immutable and entities can be mutable and value objects will not have nay table in database.

Stagecraft

Answer 8

I asked about this in another thread and I think I'm still confused. I may be confusing performance considerations with data modelling. In our Cataloging application, a Customer doesn't change until it needs to. That sounds dumb - but the 'reads' of customer data far outnumber the 'writes' and since many many web requests are all hitting on the 'active set' of objects, I don't want to keep loading Customers time and again. So I was headed down an immutable road for the Customer object - load it, cache it, and serve up the same one to the 99% of (multi-threaded) requests that want to see the Customer. Then, when a customer changes something, get an 'editor' to make a new Customer and invalidate the old one.

My concern is if many threads see the same customer object and it is mutable, then when one thread starts to change it mayhem ensues in the others.

My problems now are, 1) is this reasonable, and 2) how best to do this without duplicating a lot of code about the properties.

Canasta

Answer 9

Consider the following examples from Wikipedia, in order to better understand the difference between Value Objects and Entities:

Value Object: When people exchange dollar bills, they generally do not distinguish between each unique bill; they only are concerned about the face value of the dollar bill. In this context, dollar bills are Value Objects. However, the Federal Reserve may be concerned about each unique bill; in this context each bill would be an entity.

Entity: Most airlines distinguish each seat uniquely on every flight. Each seat is an entity in this context. However, Southwest Airlines, EasyJet and Ryanair do not distinguish between every seat; all seats are the same. In this context, a seat is actually a Value Object.

Nil