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

We Can See Clearly Now
As we search for a better model, we have significant advantages over the original designers,
because of the knowledge crunching and refactoring to deeper insight that has happened in the
interim. For example, we compute color using a 
SIDE-EFFECT-FREE FUNCTION
on a 
VALUE OBJECT
. This
means we can repeat the calculation any time we need to. We should take advantage of that.
We seem to be giving 
Paint
two different basic responsibilities. Let's try splitting them.
Now there is only one command, 
mixIn()
. It just adds an object to a collection, an effect apparent
from an intuitive understanding of the model. All other operations are 
SIDE-EFFECT-FREE FUNCTIONS
.
A test method confirming one of the 
ASSERTIONS
listed in Figure 10.10 could look something like
this (using the JUnit test framework):
public void testMixingVolume {
PigmentColor yellow = new PigmentColor(0, 50, 0);
PigmentColor blue = new PigmentColor(0, 0, 50);
StockPaint paint1 = new StockPaint(1.0, yellow);
StockPaint paint2 = new StockPaint(1.5, blue);
MixedPaint mix = new MixedPaint();
mix.mixIn(paint1);
mix.mixIn(paint2);
assertEquals(2.5, mix.getVolume(), 0.01);
}
Figure 10.10.

---

This model captures and communicates more of the domain. The invariants and post-conditions
make common sense, which will make them easier to maintain and use.
The communicativeness of the 
INTENTION-REVEALING INTERFACES
, combined with the predictability
given by 
SIDE-EFFECT-FREE FUNCTIONS
and 
ASSERTIONS
, should make encapsulation and abstraction
safe.
The next ingredient in recombinable elements is effective decomposition. . . .
[ Team LiB ]

---

[ Team LiB ]