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

Repositories
Associations allow us to find an object based on its relationship to another. But we must have a
starting point for a traversal to an 
ENTITY
or 
VALUE
in the middle of its life cycle.
To do anything with an object, you have to hold a reference to it. How do you get that reference?
One way is to create the object, as the creation operation will return a reference to the new
object. A second way is to traverse an association. You start with an object you already know and
ask it for an associated object. Any object-oriented program is going to do a lot of this, and these
links give object models much of their expressive power. But you have to get that first object.
I actually encountered a project once in which the team was attempting, in an enthusiastic
embrace of 
MODEL-DRIVEN DESIGN
, to do 
all
object access by creation or traversal! Their objects
resided in an object database, and they reasoned that existing conceptual relationships would
provide all necessary associations. They needed only to analyze them enough, making their entire
domain model cohesive. This self-imposed limitation forced them to create just the kind of endless
tangle that we have been trying to avert over the last few chapters, with careful implementation of
ENTITIES
and application of 
AGGREGATES
. The team members didn't stick with this strategy long, but
they never replaced it with another coherent approach. They cobbled together ad hoc solutions
and became less ambitious.
Few would even think of this approach, much less be tempted by it, because they store most of

---

their objects in relational databases. This storage technology makes it natural to use the third way
of getting a reference: Execute a query to find the object in a database based on its attributes, or
find the constituents of an object and then reconstitute it.
A database search is globally accessible and makes it possible to go directly to any object. There is
no need for all objects to be interconnected, which allows us to keep the web of objects
manageable. Whether to provide a traversal or depend on a search becomes a design decision,
trading off the decoupling of the search against the cohesiveness of the association. Should the
Customer object hold a collection of all the Orders placed? Or should the Orders be found in the
database, with a search on the Customer ID field? The right combination of search and association
makes the design comprehensible.
Unfortunately, developers don't usually get to think much about such design subtleties, because
they are swimming in the sea of mechanisms needed to pull off the trick of storing an object and
bringing it back—and eventually removing it from storage.
Now from a technical point of view, retrieval of a stored object is really a subset of creation,
because the data from the database is used to assemble new objects. Indeed, the code that
usually has to be written makes it hard to forget this reality. But conceptually, this is the 
middle
of
the life cycle of an 
ENTITY
. A Customer object does not represent a new customer just because we
stored it in a database and retrieved it. To keep this distinction in mind, I refer to the creation of
an instance from stored data as 
reconstitution
.
The goal of domain-driven design is to create better software by focusing on a model of the
domain rather than the technology. By the time a developer has constructed an SQL query,
passed it to a query service in the infrastructure layer, obtained a result set of table rows, pulled
the necessary information out, and passed it to a constructor or 
FACTORY
, the model focus is gone.
It becomes natural to think of the objects as containers for the data that the queries provide, and
the whole design shifts toward a data-processing style. The details of the technology vary, but the
problem remains that the client is dealing with technology, rather than model concepts.
Infrastructure such as 
METADATA MAPPING LAYERS
(Fowler 2002) help a great deal, by making easier
the conversion of the query result into objects, but the developer is still thinking about technical
mechanisms, not the domain. Worse, as client code uses the database directly, developers are
tempted to bypass model features such as 
AGGREGATES,
or even object encapsulation, instead
directly taking and manipulating the data they need. More and more domain rules become
embedded in query code or simply lost. Object databases do eliminate the conversion problem, but
search mechanisms are usually still mechanistic, and developers are still tempted to grab whatever
objects they want.