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

unit tests for them. Write them into documentation or diagrams where it fits the style
of the project's development process.
Seek models with coherent sets of concepts, which lead a developer to infer the
intended 
ASSERTIONS
, accelerating the learning curve and reducing the risk of
contradictory code.
Even though many object-oriented languages don't currently support 
ASSERTIONS
directly,
ASSERTIONS
are still a powerful way of thinking about a design. Automated unit tests can partially

---

compensate for the lack of language support. Because 
ASSERTIONS
are all in terms of states, rather
than procedures, they make tests easy to write. The test setup puts the preconditions in place;
then, after execution, the test checks to see if the post-conditions hold.
Clearly stated invariants and pre- and post-conditions allow a developer to understand the
consequences of using an operation or object. Theoretically, any noncontradictory set of assertions
would work. But humans don't just compile predicates in their heads. They will be extrapolating
and interpolating the concepts of the model, so it is important to find models that make sense to
people as well as satisfying the needs of the application.
Example
Back to Paint Mixing
Recall that in the previous example I was concerned about the ambiguity of what happens to the
argument of the 
mixIn(Paint)
operation on the 
Paint
class.
Figure 10.9.
The receiver's volume is increased by the amount of the argument's volume. Drawing on our
general understanding of physical paint, this mixing process should deplete the other paint by the
same amount, draining it to zero volume, or eliminating it completely. The current implementation
does not modify the argument, and modifying arguments is a particularly risky kind of side effect
anyway.
To start on a solid footing, let's state the post-condition of the 
mixIn()
method 
as it is
:
After 
p1.mixIn(p2):
p1.volume
is increased by amount of 
p2.volume
.
p2.volume
is unchanged.
The trouble is, developers are going to make mistakes, because these properties don't fit the
concepts we have invited them to think about. The straightforward fix would be change the volume
of the other paint to zero. Changing an argument is a bad practice, but it would be easy and
intuitive. We could state an invariant:
Total volume of paint is unchanged by mixing.
But wait! While developers were pondering this option, they made a discovery. It turns out that
there was a compelling reason the original designers made it this way. At the end, the program

---

reports the list of unmixed paints that were added
. After all, the ultimate purpose of this
application is to help a user figure out which paints to 
put into
a mixture.
So, to make the volume model logically consistent would make it unsuitable for its application
requirements. There seems to be a dilemma. Are we stuck with documenting the weird post-
condition and trying to compensate with good communication? Not everything in this world is
intuitive, and sometimes that is the best answer. But in this case, the awkwardness seems to point
to missing concepts. Let's look for a new model.