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

Designing Associations That Involve V
ALUE
 O
BJECTS
Most of the earlier discussion of associations applies to 
ENTITIES
and 
VALUE OBJECTS
alike. The fewer
and simpler the associations in the model, the better.
But, while bidirectional associations between 
ENTITIES
may be hard to maintain, bidirectional
associations between two 
VALUE OBJECTS
just make no sense. Without identity, it is meaningless to
say that an object points back to the same 
VALUE OBJECT
that points to it. The most you could say
is that it points to an object that is 
equal
to the one pointing to it, but you would have to enforce
that invariant somewhere. And although you could do so, and set up pointers going both ways, it
is hard to think of examples where such an arrangement would be useful. Try to completely
eliminate bidirectional associations between 
VALUE OBJECTS
. If in the end such associations seem
necessary in your model, rethink the decision to declare the object a 
VALUE OBJECT
in the first
place. Maybe it has an identity that hasn't been explicitly recognized yet.
E
NTITIES
and 
VALUE OBJECTS
are the main elements of conventional object models, but pragmatic
designers have come to use one element, 
SERVICES
. . . .
[ Team LiB ]

---

[ Team LiB ]
Services
Sometimes, it just isn't a thing.
In some cases, the clearest and most pragmatic design includes operations that do not
conceptually belong to any object. Rather than force the issue, we can follow the natural contours
of the problem space and include 
SERVICES
explicitly in the model.
There are important domain operations that can't find a natural home in an 
ENTITY
or 
VALUE
OBJECT
. Some of these are intrinsically activities or actions, not things, but since our modeling
paradigm is objects, we try to fit them into objects anyway.
Now, the more common mistake is to give up too easily on fitting the behavior into an appropriate
object, gradually slipping toward procedural programming. But when we force an operation into an
object that doesn't fit the object's definition, the object loses its conceptual clarity and becomes
hard to understand or refactor. Complex operations can easily swamp a simple object, obscuring
its role. And because these operations often draw together many domain objects, coordinating
them and putting them into action, the added responsibility will create dependencies on all those
objects, tangling concepts that could be understood independently.
Sometimes services masquerade as model objects, appearing as objects with no meaning beyond
doing some operation. These "doers" end up with names ending in "Manager" and the like. They
have no state of their own nor any meaning in the domain beyond the operation they host. Still, at
least this solution gives these distinct behaviors a home without messing up a real model object.