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

1.
Related rules appear in multiple objects, forcing duplication or inheritance between objects
that are not otherwise a family.
2.
A lot of design and requirements conversation revolves around the constraints, but in the
implementation, they are hidden away in procedural code.
3.
When the constraints are obscuring the object's basic responsibility, or when the constraint is
prominent in the domain yet not prominent in the model, you can factor it out into an explicit
object or even model it as a set of objects and relationships. (One in-depth, semiformal treatment
of this subject can be found in 
The Object Constraint Language: Precise Modeling with UML
[Warmer and Kleppe 1999].)

---

Example
Review: Overbooking Policy
In Chapter 1, we worked with a common shipping business practice: booking 10 percent more
cargo than the transports could handle. (Experience has taught shipping firms that this
overbooking compensates for last-minute cancellations, so their ships will sail nearly full.)
This constraint on the association between 
Voyage
and 
Cargo 
was made explicit, both in the
diagrams and in the code, by adding a new class that represented the constraint.
Figure 9.11. The model refactored to make policy explicit
To review the code and reasoning in the full example, see page 17.
Processes as Domain Objects
Right up front, let's agree that we do 
not
want to make procedures a prominent aspect of our
model. Objects are meant to encapsulate the procedures and let us think about their goals or
intentions instead.
What I am talking about here are processes that exist in the domain, which we have to represent
in the model. When these emerge, they tend to make for awkward object designs.
The first example in this chapter described a shipping system that routed cargo. This routing
process was something with business meaning. A 
SERVICE
is one way of expressing such a process
explicitly, while still encapsulating the extremely complex algorithms.
When there is more than one way to carry out a process, another approach is to make the
algorithm itself, or some key part of it, an object in its own right. The choice between processes
becomes a choice between these objects, each of which represents a different 
STRATEGY
. (Chapter
12 will look in more detail at the use of 
STRATEGIES
in the domain.)
The key to distinguishing a process that ought to be made explicit from one that should be hidden
is simple: Is this something the domain experts talk about, or is it just part of the mechanism of
the computer program?
Constraints and processes are two broad categories of model concepts that don't come leaping to
mind when programming in an object-oriented language, yet they can really sharpen up a design
once we start thinking about them as model elements.
Some useful categories of concepts are much narrower. I'll round out this chapter with one much
more specific, yet quite common. S
PECIFICATION
provides a concise way of expressing certain kinds
of rules, extricating them from conditional logic and making them explicit in the model.

---

I developed 
SPECIFICATION
in collaboration with Martin Fowler (Evans and Fowler 1997). The
simplicity of the concept belies the subtlety in application and implementation, so there is a lot of
detail in this section. There will be even more discussion in Chapter 10, where the pattern is
extended. After reading the initial explanation of the pattern that follows, you may want to skim
the "Applying and Implementing S
PECIFICATIONS
" section, until you are actually attempting to apply
the pattern.