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

A client needs a practical means of acquiring references to preexisting domain objects.
If the infrastructure makes it easy to do so, the developers of the client may add more
traversable associations, muddling the model. On the other hand, they may use queries
to pull the exact data they need from the database, or to pull a few specific objects
rather than navigating from 
AGGREGATE
 roots. Domain logic moves into queries and
client code, and the 
ENTITIES
 and 
VALUE OBJECTS
 become mere data containers. The sheer
technical complexity of applying most database access infrastructure quickly swamps
the client code, which leads developers to dumb down the domain layer, which makes
the model irrelevant.
Drawing on the design principles discussed so far, we can reduce the scope of the object access
problem somewhat, assuming that we find a method of access that keeps the model focus sharp
enough to employ those principles. For starters, we need not concern ourselves with transient
objects. Transients (typically 
VALUE OBJECTS
) live brief lives, used in the client operation that
created them and then discarded. We also need no query access for persistent objects that are
more convenient to find by traversal. For example, the address of a person could be requested
from the Person object. And most important, 
any object internal to an 
AGGREGATE
 is prohibited
from access except by traversal from the root
.

---

Persistent 
VALUE OBJECTS
are usually found by traversal from some 
ENTITY
that acts as the root of
the 
AGGREGATE
that encapsulates them. In fact, a global search access to a 
VALUE
is often
meaningless, because finding a 
VALUE
by its properties would be equivalent to creating a new
instance with those properties. There are exceptions, though. For example, when I am planning
travel online, I sometimes save a few prospective itineraries and return later to select one to book.
Those itineraries are 
VALUES
(if there were two made up of the same flights, I would not care which
was which), but they have been associated with my user name and retrieved for me intact.
Another case would be an "enumeration," when a type has a strictly limited, predetermined set of
possible values. Global access to 
VALUE OBJECTS
is much less common than for 
ENTITIES
, though,
and if you find you need to search the database for a preexisting 
VALUE
, it is worth considering the
possibility that you've really got an 
ENTITY
whose identity you haven't recognized.
From this discussion, it is clear that most objects should not be accessed by a global search. It
would be nice for the design to communicate those that do.
Now the problem can be restated more precisely.