Yes, it’s very useful to be able to distinguish, especially when you design and implement your types.
One of the main differences is when it comes to equality, since entities must have completely different behavior than Value objects. Knowing whether your object is an object or a Value object indicates how you should implement equality for the type. This is useful in itself, but it does not stop there.
Objects are mutable types (at least in concept). The whole idea of Entity is that it is a domain concept with a known progression of life (i.e., it has been created, it undergoes several transformations, is archived and, possibly, is ultimately deleted). It represents the same “thing”, even if months or years pass, and it changes its state along this path.
Value objects, on the other hand, simply represent values without any inherent identifier. Although you do not need to do this, they very well established themselves as immutable types. This is very interesting because any immutable type is, by definition, thread safe. Since we are moving into a multi-core age, it is very important to know when to implement an object as an immutable type.
It also helps in unit testing when equality semantics are well known. In both cases, equality is clearly defined. I don’t know which language you use, but in many languages (C #, Java, VB.NET), equality is defined by default by default, which in many cases is not particularly useful.
Mark seemann
source share