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

A Declarative Style of Design
Once your design has 
INTENTION-REVEALING INTERFACES
, 
SIDE-EFFECT-FREE FUNCTIONS
, and
ASSERTIONS
, you are edging into declarative territory. Many of the benefits of declarative design
are obtained once you have combinable elements that communicate their meaning, and have
characterized or obvious effects, or no observable effects at all.
A supple design can make it possible for the client code to use a declarative 
style
of design. To
illustrate, the next section will bring together some of the patterns in this chapter to make the
SPECIFICATION
more supple and declarative.
Extending S
PECIFICATIONS
 in a Declarative Style
Chapter 9 covered the basic concept of 
SPECIFICATION
, the roles it can play in a program, and some
sense of what is involved in implementation. Now let's take a look at a few bells and whistles that
can be very useful in some situations with complicated rules.
S
PECIFICATION
is an adaptation of an established formalism, the predicate. Predicates have other
useful properties that we can draw on, selectively.
Combining S
PECIFICATIONS
 Using Logical Operators
When using 
SPECIFICATIONS
, you quickly come across situations in which you would like to combine
them. As just mentioned, a 
SPECIFICATION
is an example of a predicate, and predicates can be
combined and modified with the operations "AND," "OR," and "NOT." These logical operations are
closed under predicates, so 
SPECIFICATION
combinations will exhibit 
CLOSURE OF OPERATIONS
.
As significant generalized capability is built into 
SPECIFICATIONS
, it becomes very useful to create an
abstract class or interface that can be used for 
SPECIFICATIONS
of all sorts. This means typing
arguments as some high-level abstract class.
public interface Specification {
boolean isSatisfiedBy(Object candidate);
}
This abstraction calls for a guard clause at the beginning of the method, but otherwise it does not
affect functionality. For example, the