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

Business rules often do not fit the responsibility of any of the obvious 
ENTITIES
 or 
VALUE

---

OBJECTS
, and their variety and combinations can overwhelm the basic meaning of the
domain object. But moving the rules out of the domain layer is even worse, since the
domain code no longer expresses the model.
Logic programming provides the concept of separate, combinable, rule objects called
"predicates," but full implementation of this concept with objects is cumbersome. It is
also so general that it doesn't communicate intent as much as more specialized
designs.
Fortunately, we don't really need to fully implement logic programming to get a large benefit. Most
of our rules fall into a few special cases. We can borrow the concept of predicates and create
specialized objects that evaluate to a Boolean. Those testing methods that get out of hand will
neatly expand into objects of their own. They are little truth tests that can be factored out into a
separate 
VALUE OBJECT
. This new object can evaluate another object to see if the predicate is true
for that object.
Figure 9.12.
To put it another way, the new object is a 
specification
. A 
SPECIFICATION
states a constraint on the
state of another object, which may or may not be present. It has multiple uses, but one that
conveys the most basic concept is that a 
SPECIFICATION
can test any object to see if it satisfies the
specified criteria.
Therefore:
Create explicit predicate-like 
VALUE OBJECTS
 for specialized purposes. A 
SPECIFICATION
 is
a predicate that determines if an object does or does not satisfy some criteria.
Many 
SPECIFICATIONS
are simple, special-purpose tests, as in the delinquent invoice example. In
cases where the rules are complex, the concept can be extended to allow simple specifications to
be combined, just as predicates are combined with logical operators. (This technique will be
discussed in the next chapter.) The fundamental pattern stays the same and provides a path from
the simpler to more complex models.
The case of the delinquent invoice can be modeled using a 
SPECIFICATION
that states what it means
to be delinquent and that can evaluate any