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

Design free-for-alls produce systems no one can make sense of as a whole, and they
are very difficult to maintain. But architectures can straitjacket a project with up-front
design assumptions and take too much power away from the developers/designers of
particular parts of the application. Soon, developers will dumb down the application to
fit the structure, or they will subvert it and have no structure at all, bringing back the
problems of uncoordinated development.
The problem is not the existence of guiding rules, but rather the rigidity and source of those rules.
If the rules governing the design really fit the circumstances, they will not get in the way but
actually push development in a helpful direction, as well as provide consistency.
Therefore:
Let this conceptual large-scale structure evolve with the application, possibly changing
to a completely different type of structure along the way. Don't overconstrain the
detailed design and model decisions that must be made with detailed knowledge.
Individual parts have natural or useful ways of being organized and expressed that may not apply
to the whole, so imposing global rules makes these parts less ideal. Choosing to use a large-scale
structure favors manageability of the model as a whole over optimal structuring of the individual
parts. Therefore, there will be some compromise between unifying structure and freedom to
express individual components in the most natural way. This can be mitigated by selecting the
structure based on actual experience and knowledge of the domain and by avoiding over-
constrictive structures. A really nice fit of structure to domain and requirements actually makes
detailed modeling and design easier, by helping to quickly eliminate a lot of options.

---

The structure can also give shortcuts to design decisions that could, in principle, be found by
working on the individual object level, but would, in practice, take too long and have inconsistent
results. Of course, continuous refactoring is still necessary, but this will make it a more
manageable process and can help make different people come up with consistent solutions.
A large-scale structure generally needs to be applicable across 
BOUNDED CONTEXTS
. Through
iteration on a real project, a structure will lose features that tightly bind it to a particular model
and evolve features that correspond to 
CONCEPTUAL CONTOURS
of the domain. This doesn't mean
that it will have 
no
assumptions about the model, but it will not impose upon the entire project
ideas tailored to a particular local situation. It has to leave freedom for development teams in
distinct 
CONTEXTS
to vary the model in ways that address their local needs.
Also, large-scale structures must accommodate practical constraints on development. For
example, designers may have no control over the model of some parts of the system, especially in
the case of external or legacy subsystems. This could be handled by changing the structure to
better fit the specific external elements. It could be handled by specifying ways in which the
application relates to externals. It might be handled by making the structure loose enough to flex
around awkward realities.
Unlike the 
CONTEXT MAP
, a large-scale structure is optional. One should be imposed when costs and
benefits favor it, and when a fitting structure is found. In fact, it is not needed for systems that are
simple enough to be understood when broken into 
MODULES
.