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

to developers' work assignments. Even developers who refactor a lot tend to content
themselves with 
MODULES
 conceived early in the project.
It is a truism that there should be low coupling between 
MODULES
 and high cohesion
within them. Explanations of coupling and cohesion tend to make them sound like
technical metrics, to be judged mechanically based on the distributions of associations
and interactions. Yet it isn't just code being divided into 
MODULES
, but concepts. There is
a limit to how many things a person can think about at once (hence low coupling).
Incoherent fragments of ideas are as hard to understand as an undifferentiated soup of
ideas (hence high cohesion).
Low coupling and high cohesion are general design principles that apply as much to individual
objects as to 
MODULES
, but they are particularly important at this larger grain of modeling and
design. These terms have been around for a long time; one patterns-style explanation can be
found in Larman 1998.
Whenever two model elements are separated into different modules, the relationships between
them become less direct than they were, which increases the overhead of understanding their
place in the design. Low coupling between 
MODULES
minimizes this cost, and makes it possible to
analyze the contents of one 
MODULE
with a minimum of reference to others that interact.
At the same time, the elements of a good model have synergy, and well-chosen 
MODULES
bring
together elements of the model with particularly rich conceptual relationships. This high cohesion
of objects with related responsibilities allows modeling and design work to concentrate within a
single 
MODULE
, a scale of complexity a human mind can easily handle.
M
ODULES
and the smaller elements should coevolve, but typically they do not. M
ODULES
are chosen
to organize an early form of the objects. After that, the objects tend to change in ways that keep
them in the bounds of the existing 
MODULE
definition. Refactoring 
MODULES
is more work and more
disruptive than refactoring classes, and probably can't be as frequent. But just as model objects
tend to start out naive and concrete and then gradually transform to reveal deeper insight,
MODULES
can become subtle and abstract. Letting the 
MODULES
reflect changing understanding of
the domain will also allow more freedom for the objects within them to evolve.
Like everything else in a domain-driven design, 
MODULES
are a 
communications mechanism
. The
meaning
of the objects being partitioned needs to drive the choice of 
MODULES
. When you place
some classes together in a 
MODULE
, you are telling the next developer who looks at your design to
think about them together. If your model is telling a story, the 
MODULES
are chapters. The name of

---

the 
MODULE
conveys its meaning. These names enter the 
UBIQUITOUS LANGUAGE
. "Now let's talk
about the 'customer' module," you might say to a business expert, and the context is set for your
conversation.
Therefore: