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

Pigment Color
mixedWith()
operation was closed under 
Pigment
Colors
, and there are several other examples scattered through the book. Here's an example that
shows how useful this idea can be, even when true 
CLOSURE
isn't reached.
Example
Selecting from Collections
In Java, if you want to select a subset of elements from a 
Collection
, you request an 
Iterator
.
Then you iterate through the elements, testing each one, probably accumulating the matches into
a new 
Collection
.
Set employees = (some Set of Employee objects);
Set lowPaidEmployees = new HashSet();
Iterator it = employees.iterator();
while (it.hasNext()) {
Employee anEmployee = it.next();
if (anEmployee.salary() < 40000)
lowPaidEmployees.add(anEmployee);
}
Conceptually, I've selected a subset of a set. What do I need with this extra concept, 
Iterator,
and all its mechanical complexity? In Smalltalk, I would call the "select" operation on the
Collection
, passing in the test as an argument. The return would be a new 
Collection 
containing
just the elements that passed the test.
employees := (some Set of Employee objects).
lowPaidEmployees := employees select:
[:anEmployee | anEmployee salary < 40000].
The Smalltalk 
Collections
provide other such 
FUNCTIONS
that return derived 
Collections
, which
can be of several concrete classes. The operations are not closed, because they take a "block" as
an argument. But blocks are a basic library type in Smalltalk, so they don't add to the developer's
mental load. Because the return value matches the implementer, they can be strung together, like
a series of filters. They are easy to write and easy to read. They do not introduce extraneous
concepts that are irrelevant to the problem of selecting subsets.
The patterns presented in this chapter illustrate a general style of design and a way of thinking
about design. Making software obvious, predictable, and communicative makes abstraction and
encapsulation effective. Models can be factored so that objects are simple to use and understand
yet still have rich, high-level interfaces.
These techniques require fairly advanced design skills to apply and sometimes even to write a
client. The usefulness of a 
MODEL-DRIVEN DESIGN
is sensitive to the quality of the detailed design
and implementation decisions, and it only takes a few confused developers to derail a project from
the goal.
That said, for the team willing to cultivate its modeling and design skills, these patterns and the
way of thinking they reflect yield software that developers can work and rework to create complex

---

software.
[ Team LiB ]

---

[ Team LiB ]