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

Refactoring Toward a Fitting Structure
In an era when the industry is shaking off excessive up-front design, some will see large-scale
structure as a throwback to the bad old days of waterfall architecture. But in fact, the only way a
useful structure can be found is from a very deep understanding of the domain and the problem,
and the practical way to that understanding is an iterative development process.
A team committed to 
EVOLVING ORDER
must fearlessly rethink the large-scale structure throughout
the project life cycle. The team should not saddle itself with a structure conceived of early on,
when no one understood the domain or the requirements very well.
Unfortunately, that evolution means that your final structure will not be available at the start, and
that means that you will have to refactor to impose it as you go along. This can be expensive and
difficult, but it is 
necessary
. There are some general ways of controlling the cost and maximizing
the gain.
Minimalism
One key to keeping the cost down is to keep the structure simple and lightweight. Don't attempt to
be comprehensive. Just address the most serious concerns and leave the rest to be handled on a
case-by-case basis.
Early on, it can be helpful to choose a loose structure, such as a 
SYSTEM METAPHOR
or a couple of
RESPONSIBILITY LAYERS
. A minimal, loose structure can nonetheless provide lightweight guidelines
that will help prevent chaos.
Communication and Self-Discipline
The entire team must follow the structure in new development and refactoring. To do this, the
structure must be understood by the entire team. The terminology and relationships must enter
the 
UBIQUITOUS LANGUAGE
.
Large-scale structure can provide a vocabulary for the project to deal with the system broadly,
and for different people independently to make harmonious decisions. But because most large-
scale structures are loose conceptual guidelines, the teams must exercise self-discipline.
Without consistent adherence by the many people involved, structures have a tendency to decay.
The relationship of the structure to detailed parts of the model or implementation is not usually
explicit in the code, and functional tests do not rely on the structure. Plus, the structure tends to
be abstract, so that consistency of application can be difficult to maintain across a large team (or
multiple teams).
The kinds of conversations that take place on most teams are not enough to maintain a consistent
large-scale structure in a system. It is critical to incorporate it into the 
UBIQUITOUS LANGUAGE
of the
project, and for everyone to exercise that language relentlessly.