Domain-Driven Design: Tackling Complexity in the Heart of Software

Value Objects
Many objects have no conceptual identity. These objects describe some characteristic of a thing.
When a child is drawing, he cares about the color of the marker he chooses, and he may care
about the sharpness of the tip. But if there are two markers of the same color and shape, he
probably won't care which one he uses. If a marker is lost and replaced by another of the same
color from a new pack, he can resume his work unconcerned about the switch.
Ask the child about the various drawings on the refrigerator, and he will quickly distinguish those
he made from those his sister made. He and his sister have useful identities, as do their completed
drawings. But imagine how complicated it would be if he had to track which lines in a drawing were
made by each marker. Drawing would no longer be child's play.
Because the most conspicuous objects in a model are usually 
ENTITIES
, and because it is so
important to track each 
ENTITY
's identity, it is natural to consider assigning an identity to all
domain objects. Indeed, some frameworks assign a unique ID to every object.
The system has to cope with all that tracking, and many possible performance optimizations are
ruled out. Analytical effort is required to define meaningful identities and work out foolproof ways
to track objects across distributed systems or in database storage. Equally important, taking on
artificial identities is misleading. It muddles the model, forcing all objects into the same mold.
Tracking the identity of 
ENTITIES
 is essential, but attaching identity to other objects can
hurt system performance, add analytical work, and muddle the model by making all
objects look the same.
Software design is a constant battle with complexity. We must make distinctions so
that special handling is applied only where necessary.