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

Choosing Appropriate Layers
Finding good 
RESPONSIBILITY LAYERS
, or any large-scale structure, is a matter of understanding the
problem domain and experimenting. If you allow 
EVOLVING ORDER
, the initial starting point is not
critical, although a poor choice does add work. The structure may well evolve into something
unrecognizable. So the guidelines suggested here should be applied when considering
transformations of the structure as much as when choosing from scratch.
As layers get switched out, merged, split, and redefined, here are some useful characteristics to
look for and preserve.
Storytelling
. The layers should communicate the basic realities or priorities of the domain.
Choosing a large-scale structure is less a technical decision than a business modeling
decision. The layers should bring out the priorities of the business.
Conceptual dependency
. The concepts in the "upper" layers should have meaning against the
backdrop of the "lower" layers, while the lower-layer concepts should be meaningful standing
alone.
C
ONCEPTUAL CONTOURS
. If the objects of different layers should have different rates of change
or different sources of change, the layer accommodates the shearing between them.
It isn't always necessary to start from scratch in defining layers for each new model. Certain layers

---

show up in whole families of related domains.
For example, in businesses based on exploiting large fixed capital assets, such as factories or
cargo ships, logistical software can often be organized into a "Potential" layer (another name for
the "Capability" layer in the example) and an "Operations" layer.
Potential
. What can be done? Never mind what we are planning to do. What 
could
we do?
The resources of the organization, including its people, and the way those resources are
organized are the core of the Potential layer. Contracts with vendors also define potentials.
This layer could be recognized in almost any business domain, but it is a prominent part of
the story in those businesses, such as transportation and manufacturing, that have relatively
large fixed capital investments that enable the business. Potential includes transient assets as
well, but a business driven primarily by transient assets might choose layers that emphasize
this, as discussed later. (This layer was called "Capability" in the example.)
Operation
. What is being done? What have we managed to make of those potentials? Like
the Potential layer, this layer should reflect the reality of the situation, rather than what we
want it to be. In this layer we are trying to see our own efforts and activities: What we are
selling, rather than what enables us to sell. It is very typical of Operational objects to
reference or even be composed of Potential objects, but a Potential object shouldn't
reference the Operations layer.
In many, perhaps most, existing systems in domains of this kind, these two layers cover
everything (although there could be some entirely different and more revealing breakdown). They
track the current situation and active operational plans and issue reports or documents about it.
But tracking is not always enough. When projects seek to guide or assist users, or to automate
decision making, there is an additional set of responsibilities that can be organized into another
layer, above Operations.
Decision Support
. What action should be taken or what policy should be set? This layer is for
analysis and decision making. It bases its analysis on information from lower layers, such as
Potential or Operations. Decision Support software may use historical information to actively
seek opportunities for current and future operations.
Decision Support systems have conceptual dependencies on other layers such as Operations or
Potential because decisions aren't made in a vacuum. A lot of projects implement Decision Support
using data warehouse technology. The layer becomes a distinct 
BOUNDED CONTEXT
, with a
CUSTOMER/SUPPLIER
relationship with the Operations software. In other projects, it is more deeply
integrated, as in the preceding extended example. And one of the intrinsic advantages of layers is
that the lower layers can exist without the higher ones. This can facilitate phased introductions or
higher-level enhancements built on top of older operational systems.
Another case is software that enforces elaborate business rules or legal requirements, which can
constitute a 
RESPONSIBILITY LAYER
.
Policy
. What are the rules and goals? Rules and goals are mostly passive, but constrain the
behavior in other layers. Designing these interactions can be subtle. Sometimes a Policy is
passed in as an argument to a lower level method. Sometimes the STRATEGY pattern is
applied. Policy works well in conjunction with a Decision Support layer, which provides the
means to seek the goals set by Policy, constrained by the rules set by Policy.
Policy layers can be written in the same language as the other layers, but they are sometimes
implemented using rules engines. This doesn't necessarily place them in a separate 
BOUNDED
CONTEXT
. In fact, the difficulty of coordinating such different implementation technologies can be
eased by fastidiously using the same model across both. When rules are written based on a

---

different model than the objects they apply to, either the complexity goes way up or the objects
get dumbed down to keep things manageable.