DDD: Can immutable objects also be entities?

Question

I've read countless posts on differences between Entities and Value objects and while I do think that at least conceptually I understand how the two differ, it appears that in some of these posts authors consider a particular domain concept to be a VO simply because it is immutable ( thus its state will never change, at least within that particular domain model ).

Do you agree that if the state of an object will never change within particular domain model, then this object should never be an entity? Why?

thank you

Cipher

I saw someone give the excellent example of a an audit log somewhere. Such items tend to have an id, but must definitely never change. – Valerio

Answer 1

Do you agree that if the state of an object will never change within particular domain model, then this object should never be an entity? Why?

I'd say 90+% of entities will change at some point in their lifetime. But some entities might be unchangeable because of their nature in the domain - a PrepaidPhoneCard, a TransferOrder in a banking system for instance.

Some also like to make their Entities immutable by default because it helps shaping a design that preserves invariants and makes domain operations explicit : http://www.jefclaes.be/2013/04/designing-entities-immutability-first.html

Ailsa

Answer 2

The object could be an entity if you need to identify it. According to the DDD book, if an object has identity and lifecycle but will not change over time, you could also consider the object as an event.

Somnifacient

Which DDD book ( I'm assuming not Evan's book, since I don't think he's talking about events in it )? – Cipher

@Cipher Evan's book if I'm not mistaken. Event was not an explicit concept at that time although. The example metioned was an Payment, each payment has an sequence as it's identity. And in his dddsample project, I remember the HandlingEvent implements DomainEvent. – Somnifacient

Answer 3

In two words: yes, they can.

Eric Evans in his book tells about a "thread of continuity" inherent to entities. In layman terms, an entity can be POSTed by a front-end as JSON, get converted into a DTO by a framework, then into a domain object, then into a DTO again and then finally get stored in a database table. During all these transformations the entity will be easily distinguishable because it possesses one or more unique business ids.

With this in mind, aren't some forms of immutability a form of another thread of continuity? Imagine copy-on-write: all of the immutable object's copies are formally different objects representing it at different points of its lifetime. Yet, there is a unique id allowing us to say it's the same entity.

Now, let's talk about the "extreme" form of immutability: read-only objects. Can an entity be a read-only object? Sure, a good example is a credit card statement.

Summing up:

• One entity can exist in many forms. In fact, you will almost always have multiple representations of your entity in a program without being aware about it.
• A true requirement an entity is an existence of a unique business identity (not a surrogate id that is used for technical purposes) that makes it distinguishable from other entities.
• Entities can be immutable, whether we talk about COW or read-only objects.

Potaufeu

This approach is awful. I read that in his book and I disagreed with him here. This often results in over engineering a simple problem. You end up with mappers from contract to domain to entities and back again. Following these principles to the letter doesn't result in maintainable code in my opinion. – Jonniejonny

Answer 4

I'd say the difference between entities and value objects lies on whether identity matters or not.

Objects that never change over time can be entities as long as we care about their identities. As for value objects, there are also cases when people prefer to design them as mutable. As mentioned in Evans' book:

These factors would weigh in favor of a mutable implementation:

• If the VALUE changes frequently
• If object creation or deletion is expensive
• If replacement (rather than modification) will disturb clustering (as discussed in the previous example)
• If there is not much sharing of VALUES, or if such sharing is forgone to improve clustering or for some other technical reason

Atonality