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

Choose 
MODULES
 that tell the story of the system and contain a cohesive set of concepts.
This often yields low coupling between 
MODULES
, but if it doesn't, look for a way to
change the model to disentangle the concepts, or search for an overlooked concept that
might be the basis of a 
MODULE
 that would bring the elements together in a meaningful
way. Seek low coupling in the sense of concepts that can be understood and reasoned
about independently of each other. Refine the model until it partitions according to
highlevel domain concepts and the corresponding code is decoupled as well.
Give the 
MODULES
 names that become part of the 
UBIQUITOUS LANGUAGE
. 
MODULES
 and
their names should reflect insight into the domain.
Looking at conceptual relationships is not an alternative to technical measures. They are different
levels of the same issue, and both have to be accomplished. But model-focused thinking produces
a deeper solution, rather than an incidental one. And when there has to be a trade-off, it is best to
go with the conceptual clarity, even if it means more references between 
MODULES
or occasional
ripple effects when changes are made to a 
MODULE
. Developers can handle these problems if they
understand the story the model is telling them.
Agile M
ODULES
M
ODULES
need to coevolve with the rest of the model. This means refactoring 
MODULES
right along
with the model and code. But this refactoring often doesn't happen. Changing 
MODULES
tends to
require widespread updates to the code. Such changes can be disruptive to team communication
and can even throw a monkey wrench into development tools, such as source code control
systems. As a result, 
MODULE
structures and names often reflect much earlier forms of the model
than the classes do.
Inevitable early mistakes in 
MODULE
choices lead to high coupling, which makes it hard to refactor.
The lack of refactoring just keeps increasing the inertia. It can only be overcome by biting the
bullet and reorganizing 
MODULES
based on experience of where the trouble spots lie.
Some development tools and programming systems exacerbate the problem. Whatever
development technology the implementation will be based on, we need to look for ways of
minimizing the work of refactoring 
MODULES
, and minimizing clutter in communicating to other
developers.