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

Decompose design elements (operations, interfaces, classes, and 
AGGREGATES
) into
cohesive units, taking into consideration your intuition of the important divisions in the
domain. Observe the axes of change and stability through successive refactorings and
look for the underlying 
CONCEPTUAL CONTOURS
 that explain these shearing patterns. Align
the model with the consistent aspects of the domain that make it a viable area of
knowledge in the first place.
The goal is a simple set of interfaces that combine logically to make sensible statements in the
UBIQUITOUS LANGUAGE
, and without the distraction and maintenance burden of irrelevant options.
This is typically an outcome of refactoring: it's hard to produce up front. But it may never emerge
from technically oriented refactoring; it emerges from refactoring toward deeper insight.
Even when the design follows 
CONCEPTUAL CONTOURS
, there will need to be modifications and
refactoring. When successive refactoring tends to be localized, not shaking multiple broad concepts
of the model, it is an indicator of model fit. Encountering a requirement that forces extensive
changes in the breakdown of the objects and methods is a message: Our understanding of the
domain needs refinement. It presents an opportunity to deepen the model and make the design
more supple.
Example
The C
ONTOURS
 of Accruals
In Chapter 9, a loan tracking system was refactored based on deeper insight into accounting
concepts:
Figure 10.11.

---

The new model contained only one more object than the old one, yet the partitioning of
responsibility had been greatly changed.
Schedules, which had been worked out through case logic in the 
Calculator
classes, were
exploded into discrete classes for different types of fees and interest. On the other hand,
payments of fees and interest, previously kept separate, were lumped together.
Because of the resonance of the newly explicit concepts and the cohesiveness of the