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

Implementing a R
EPOSITORY
Implementation will vary greatly, depending on the technology being used for persistence and the
infrastructure you have. The ideal is to hide all the inner workings from the client (although not
from the developer of the client), so that client code will be the same whether the data is stored in
an object database, stored in a relational database, or simply held in memory. The 
REPOSITORY
will
delegate to the appropriate infrastructure services to get the job done. Encapsulating the
mechanisms of storage, retrieval, and query is the most basic feature of a 
REPOSITORY
implementation.
Figure 6.21. The 
REPOSITORY
 encapsulates the underlying data store.
The 
REPOSITORY
concept is adaptable to many situations. The possibilities of implementation are so

---

diverse that I can only list some concerns to keep in mind.
Abstract the type
. A 
REPOSITORY
"contains" all instances of a specific type, but this does not
mean that you need one 
REPOSITORY
for each class. The type could be an abstract superclass
of a hierarchy (for example, a 
TradeOrder
could be a 
BuyOrder
or a 
Sell-Order
). The type
could be an interface whose implementers are not even hierarchically related. Or it could be a
specific concrete class. Keep in mind that you may well face constraints imposed by the lack
of such polymorphism in your database technology.
Take advantage of the decoupling from the client
. You have more freedom to change the
implementation of a 
REPOSITORY
than you would if the client were calling the mechanisms
directly. You can take advantage of this to optimize for performance, by varying the query
technique or by caching objects in memory, freely switching persistence strategies at any
time. You can facilitate testing of the client code and the domain objects by providing an
easily manipulated, dummy in-memory strategy.
Leave transaction control to the client
. Although the 
REPOSITORY
will insert into and delete
from the database, it will ordinarily not commit anything. It is tempting to commit after
saving, for example, but the client presumably has the context to correctly initiate and
commit units of work. Transaction management will be simpler if the 
REPOSITORY
keeps its
hands off.
Typically teams add a framework to the infrastructure layer to support the implementation of
REPOSITORIES
. In addition to the collaboration with the lower level infrastructure components, the
REPOSITORY
superclass might implement some basic queries, especially when a flexible query is
being implemented. Unfortunately, with a type system such as Java's, this approach would force
you to type returned objects as "Object," leaving the client to cast them to the 
REPOSITORY'S
contained type. But of course, this will have to be done with queries that return collections anyway
in Java.
Some additional guidance on implementing 
REPOSITORIES
and some of their supporting technical
patterns such as 
QUERY OBJECT
can be found in Fowler (2002).