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

Figure 6.18. A 
REPOSITORY
 doing a search for a client

---

A 
REPOSITORY
lifts a huge burden from the client, which can now talk to a simple, intention-
revealing interface, and ask for what it needs in terms of the model. To support all this requires a
lot of complex technical infrastructure, but the interface is simple and conceptually connected to
the domain model.
Therefore:
For each type of object that needs global access, create an object that can provide the
illusion of an in-memory collection of all objects of that type. Set up access through a
well-known global interface. Provide methods to add and remove objects, which will
encapsulate the actual insertion or removal of data in the data store. Provide methods
that select objects based on some criteria and return fully instantiated objects or
collections of objects whose attribute values meet the criteria, thereby encapsulating
the actual storage and query technology. Provide 
REPOSITORIES
 only for 
AGGREGATE
 roots
that actually need direct access. Keep the client focused on the model, delegating all
object storage and access to the 
REPOSITORIES
.
R
EPOSITORIES
have many advantages, including the following:
They present clients with a simple model for obtaining persistent objects and managing their
life cycle.
They decouple application and domain design from persistence technology, multiple database
strategies, or even multiple data sources.
They communicate design decisions about object access.
They allow easy substitution of a dummy implementation, for use in testing (typically using
an in-memory collection).
Querying a R
EPOSITORY
All repositories provide methods that allow a client to request objects matching some criteria, but
there is a range of options of how to design this interface.
The easiest 
REPOSITORY
to build has hard-coded queries with specific parameters. These queries
can be various: retrieving an 
ENTITY
by its identity (provided by almost all 
REPOSITORIES
);
requesting a collection of objects with a particular attribute value or a complex combination of
parameters; selecting objects based on value ranges (such as date ranges); and even performing
some calculations that fall within the general responsibility of a 
REPOSITORY
(especially drawing on
operations supported by the underlying database).

---

Although most queries return an object or a collection of objects, it also fits within the concept to
return some types of summary calculations, such as an object count, or a sum of a numerical
attribute that was intended by the model to be tallied.