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

If the design, or some central part of it, does not map to the domain model, that model
is of little value, and the correctness of the software is suspect. At the same time,
complex mappings between models and design functions are difficult to understand
and, in practice, impossible to maintain as the design changes. A deadly divide opens
between analysis and design so that insight gained in each of those activities does not
feed into the other.
An analysis must capture fundamental concepts from the domain in a comprehensible, expressive
way. The design has to specify a set of components that can be constructed with the programming
tools in use on the project that will perform efficiently in the target deployment environment and
will correctly solve the problems posed for the application.
M
ODEL-DRIVEN DESIGN
discards the dichotomy of analysis model and design to search out a single
model that serves both purposes. Setting aside purely technical issues, each object in the design
plays a conceptual role described in the model. This requires us to be more demanding of the
chosen model, since it must fulfill two quite different objectives.
There are always many ways of abstracting a domain, and there are always many designs that can
solve an application problem. This is what makes it practical to bind the model and design. This
binding mustn't come at the cost of a weakened analysis, fatally compromised by technical
considerations. Nor can we accept clumsy designs, reflecting domain ideas but eschewing software
design principles. This approach demands a model that works well as both analysis and design.
When a model doesn't seem to be practical for implementation, we must search for a new one.
When a model doesn't faithfully express the key concepts of the domain, we must search for a
new one. The modeling and design process then becomes a single iterative loop.

---

The imperative to relate the domain model closely to the design adds one more criterion for
choosing the more useful models out of the universe of possible models. It calls for hard thinking
and usually takes multiple iterations and a lot of refactoring, but it makes the model 
relevant
.
Therefore: