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

Figure 15.1. A navigation map for strategic distillation
Like a gardener pruning a tree, clearing the way for the growth of the main branches, we are
going to apply a suite of techniques to hew away distractions in the model and focus our attention
on the part that matters most. . . .
[ Team LiB ]

---

[ Team LiB ]
Core Domain
In designing a large system, there are so many contributing components, all
complicated and all absolutely necessary to success, that the essence of the domain
model, the real business asset, can be obscured and neglected.
A system that is hard to understand is hard to change. The effect of a change is hard to foresee. A
developer who wanders outside his or her own area of familiarity gets lost. (This is particularly true
when bringing new people into a team, but even an established member of the team will struggle
unless code is very expressive and organized.) This forces people to specialize. When developers
confine their work to specific modules, it further reduces knowledge transfer. With the
compartmentalization of work, smooth integration of the system suffers, and flexibility in assigning
work is lost. Duplication crops up when a developer does not realize that a behavior already exists
elsewhere, and so the system becomes even more complex.
Those are some of the consequences of any design that is hard to understand, but there is
another, equally serious risk from losing the big picture of the domain:
The harsh reality is that not all parts of the design are going to be equally refined.
Priorities must be set. To make the domain model an asset, the model's critical core has
to be sleek and fully leveraged to create application functionality. But scarce, highly
skilled developers tend to gravitate to technical infrastructure or neatly definable