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

Figure 6.19. Hard-coded queries in a simple 
REPOSITORY
Hard-coded queries can be built on top of any infrastructure and without a lot of investment,
because they do just what some client would have had to do anyway.
On projects with a lot of querying, a 
REPOSITORY
framework can be built that allows more flexible
queries. This calls for a staff familiar with the necessary technology and is greatly aided by a
supportive infrastructure.
One particularly apt approach to generalizing 
REPOSITORIES
through a framework is to use
SPECIFICATION
-based queries. A 
SPECIFICATION
allows a client to describe (that is, specify) what it
wants without concern for how it will be obtained. In the process, an object that can actually carry
out the selection is created. This pattern will be discussed in depth in Chapter 9.
Figure 6.20. A flexible, declarative 
SPECIFICATION
 of search criteria in a
sophisticated 
REPOSITORY
The 
SPECIFICATION
-based query is elegant and flexible. Depending on the infrastructure available, it
may be a modest framework or it may be prohibitively difficult. Rob Mee and Edward Hieatt
discuss more of the technical issues involved in designing such 
REPOSITORIES
in Fowler 2002.
Even a 
REPOSITORY
design with flexible queries should allow for the addition of specialized hard-
coded queries. They might be convenience methods that encapsulate an often-used query or a
query that doesn't return the objects themselves, such as a mathematical summary of selected
objects. Frameworks that don't allow for such contingencies tend to distort the domain design or
get bypassed by developers.
Client Code Ignores R
EPOSITORY
 Implementation; Developers Do Not
Encapsulation of the persistence technology allows the client to be very simple, completely
decoupled from the implementation of the 
REPOSITORY
. But as is often the case with encapsulation,

---

the developer must understand what is happening under the hood. The performance implications
can be extreme when 
REPOSITORIES
are used in different ways or work in different ways.
Kyle Brown told me the story of getting called in on a manufacturing application based on
WebSphere that was being rolled out to production. The system was mysteriously running out of
memory after a few hours of use. Kyle browsed through the code and found the reason: At one
point, they were summarizing some information about every item in the plant. The developers had
done this using a query called "all objects," which instantiated each of the objects and then
selected the bits they needed. This code had the effect of bringing the entire database into
memory at once! The problem hadn't shown up in testing because of the small amount of test
data.
This is an obvious nono, but much more subtle oversights can present equally serious problems.
Developers need to understand the implications of using encapsulated behavior. That does not
have to mean detailed familiarity with the implementation. Well-designed components can be
characterized. (This is one of the main points of Chapter 10, "Supple Design.")
As was discussed in Chapter 5, the underlying technology may constrain your modeling choices.
For example, a relational database can place a practical limit on deep compositional object
structures. In just the same way, there must be feedback to developers in both directions between
the use of the 
REPOSITORY
and the implementation of its queries.