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

Design a portion of the software system to reflect the domain model in a very literal
way, so that mapping is obvious. Revisit the model and modify it to be implemented
more naturally in software, even as you seek to make it reflect deeper insight into the
domain. Demand a single model that serves both purposes well, in addition to
supporting a robust 
UBIQUITOUS LANGUAGE
.
Draw from the model the terminology used in the design and the basic assignment of
responsibilities. The code becomes an expression of the model, so a change to the code
may be a change to the model. Its effect must ripple through the rest of the project's
activities accordingly.
To tie the implementation slavishly to a model usually requires software development
tools and languages that support a modeling paradigm, such as object-oriented
programming.
Sometimes there will be different models for different subsystems (see Chapter 14), but only one
model should apply to a particular part of the system, throughout all aspects of the development
effort, from the code to requirements analysis.
The single model reduces the chances of error, because the design is now a direct outgrowth of
the carefully considered model. The design, and even the code itself, has the communicativeness
of a model.
Developing a single model that captures the problem and provides a practical design is easier said
than done. You can't just take any model and turn it into a workable design. The model has to be
carefully crafted to make for a practical implementation. Design and implementation techniques
have to be employed that allow code to express a model effectively (see Part II). Knowledge
crunchers explore model options and refine them into practical software elements. Development
becomes an iterative process of refining the model, the design, and the code as a single activity
(see Part III).
[ Team LiB ]

---

[ Team LiB ]