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

Figure 10.6.
Factoring out 
Pigment Color
does communicate more than the earlier version, but the
computation is the same, still in the 
mixIn()
method. When we moved out the color data, we
should have taken related behavior with it. Before we do, note that 
Pigment Color
is a 
VALUE
OBJECT
. Therefore, it should be treated as immutable. When we mixed paint, the 
Paint
object itself
was changed. It was an 
ENTITY
with an ongoing life story. In contrast, a 
Pigment Color
representing a particular shade of yellow is always exactly that. Instead, mixing will result in a new
Pigment Color
object representing the new color.

---

Figure 10.7.
public class PigmentColor {
public PigmentColor mixedWith(PigmentColor other,
double ratio) {
// Many lines of complicated color-mixing logic
// ending with the creation of a new PigmentColor object
// with appropriate new red, blue, and yellow values.
}
}
public class Paint {
public void mixIn(Paint other) {
volume = volume + other.getVolume();
double ratio = other.getVolume() / volume;
pigmentColor =
pigmentColor.mixedWith(other.pigmentColor(), ratio);
}
}
Figure 10.8.

---

Now the modification code in 
Paint
is as simple as possible. The new 
Pigment Color
class
captures knowledge and communicates it explicitly, and it provides a 
SIDE-EFFECT-FREE FUNCTION
whose result is easy to understand, 
easy to test
, and safe to use or combine with other operations.
Because it is so safe, the complex logic of color mixing is truly encapsulated. Developers using this
class don't have to understand the implementation.
[ Team LiB ]

---

[ Team LiB ]
Assertions
Separating complex computations into 
SIDE-EFFECT-FREE FUNCTIONS
cuts the problem down to size,
but there is still a residue of commands on the 
ENTITIES
that produce side effects, and anyone
using them must understand their consequences. A
SSERTIONS
make side effects explicit and easier
to deal with.
True, a command containing no complex computations may be fairly easy to interpret by
inspection. But in a design where larger parts are built of smaller ones, a command may invoke
other commands. The developer using the high-level command must understand the
consequences of each underlying command. So much for encapsulation. And because object
interfaces do not restrict side effects, two subclasses that implement the same interface can have
different side effects. The developer using them will want to know which is which to anticipate the
consequences. So much for abstraction and polymorphism.