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

Figure 10.14. C
OMPOSITE
 design of 
SPECIFICATION

---

This code was written to be as easy as possible to read in a book. As I said, there may be
situations in which this is inefficient. However, other implementation options are possible that
would minimize object count or boost speed, or perhaps be compatible with idiosyncratic
technologies present in some project. The important thing is a model that captures the key
concepts of the domain, along with animplementation that is faithful to that model. That leaves a
lot of room to solve performance problems.
Also, this full generality is not needed in many cases. In particular, AND tends to be used a lot
more than the others, and it also tends to create less implementation complexity. Don't be afraid
to implement only AND, if that is all you need.
Way back in Chapter 2, in the example dialog on page 30, the developers had apparently not
implemented the "satisfied by" behavior of their 
SPECIFICATION
. Up to that point, the 
SPECIFICATION
had been used only for building to order. Even so, the abstraction was intact, and adding
functionality was relatively easy. Using a pattern doesn't mean building features you don't need.
They can be added later, as long as the concepts don't get muddled.
Example
One Alternative Implementation of C
OMPOSITE
 S
PECIFICATION
Some implementation environments don't accommodate very fine grained objects very well. I
once worked on a project with an object database that insisted on giving an object ID to every
object and then tracking it. Each object had lots of overhead in memory space and performance,
and total address space was a limiting factor. I employed 
SPECIFICATIONS
at some important points
in the domain design, which I think was a good decision. But I used a slightly more elaborate
version of the implementation described in this chapter, which was definitely a mistake. It resulted
in millions of very fine grained objects that contributed to bogging the system down.
Here is an example of an alternative implementation that encodes the composite 
SPECIFICATION
as
a string or array encoding the logical expression, to be interpreted at runtime.
(Don't worry if you do not see how you would implement this. The important thing is to realize
that there are many ways of implementing a 
SPECIFICATION
with logical operators, and so if the
simple one is not practical in your situation, you have options.)

---