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

Working Within Your Frameworks
Before implementing something like a 
REPOSITORY
, you need to think carefully about the
infrastructure you are committed to, especially any architectural frameworks. You may find that
the framework provides services you can use to easily create a 
REPOSITORY
, or you may find that
the framework fights you all the way. You may discover that the architectural framework has
already defined an equivalent pattern of getting persistent objects. Or you may discover that it has
defined a pattern that is not like a 
REPOSITORY
at all.
For example, your project might be committed to J2EE. Looking for conceptual affinities between
the framework and the patterns of 
MODEL-DRIVEN DESIGN
(and keeping in mind that an entity bean
is 
not
the same thing as an 
ENTITY
), you may have chosen to use entity beans to correspond to
AGGREGATE
roots. The construct within the architectural framework of J2EE that is responsible for
providing access to these objects is the "EJB Home." Trying to dress up the EJB Home to look like
a 
REPOSITORY
could lead to other problems.
In general, don't fight your frameworks. Seek ways to keep the fundamentals of domain-driven
design and let go of the specifics when the framework is antagonistic. Look for affinities between
the concepts of domain-driven design and the concepts in the framework. This is assuming that
you have no choice but to use the framework. Many J2EE projects don't use entity beans at all. If
you have the freedom, choose frameworks, or parts of frameworks, that are harmonious with the

---

style of design you want to use.
The Relationship with F
ACTORIES
A 
FACTORY
handles the beginning of an object's life; a 
REPOSITORY
helps manage the middle and the
end. When objects are being held in memory, or stored in an object database, this is
straightforward. But typically there is at least some object storage in relational databases, files, or
other, non-object-oriented systems. In such cases, the retrieved data must be reconstituted into
object form.
Because the 
REPOSITORY
is, in this case, creating objects based on data, many people consider the
REPOSITORY
to 
be
a 
FACTORY
—indeed it is, from a technical point of view. But it is more useful to
keep the model in the forefront, and as mentioned before, the reconstitution of a stored object is
not the creation of a new conceptual object. In this domain-driven view of the design, 
FACTORIES
and 
REPOSITORIES
have distinct responsibilities. The 
FACTORY
makes new objects; the 
REPOSITORY
finds old objects. The client of a 
REPOSITORY
should be given the illusion that the objects are in
memory. The object may have to be reconstituted (yes, a new instance may be created), but it is
the same conceptual object, still in the middle of its life cycle.
These two views can be reconciled by making the 
REPOSITORY
delegate
object creation to a
FACTORY
, which (in theory, though seldom in practice) could also be used to create objects from
scratch.