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

Model-Driven Design
The astrolabe, used to compute star positions, is a mechanical implementation of a
model of the sky
.
Tightly relating the code to an underlying model gives the code meaning and makes the model
relevant.
A Medieval Sky Computer
Ancient Greek astronomers devised the astrolabe, which was perfected by medieval
Islamic scientists. A rotating web (called a 
rete
) represented the positions of the fixed
stars on the celestial sphere. Interchangeable plates engraved with a local spherical
coordinate system represented the views from different latitudes. Rotating the rete
against the plate enabled a calculation of celestial positions for any time and day of the
year. Conversely, given a stellar or solar position, the time could be calculated. The
astrolabe was a mechanical implementation of an object-oriented model of the sky.
Projects that have no domain model at all, but just write code to fulfill one function after another,
gain few of the advantages of knowledge crunching and communication discussed in the previous
two chapters. A complex domain will swamp them.
On the other hand, many complex projects do attempt some sort of domain model, but they don't
maintain a tight connection between the model and the code. The model they develop, possibly
useful as an exploratory tool at the outset, becomes increasingly irrelevant and even misleading.

---

All the care lavished on the model provides little reassurance that the design is correct, because
the two are different.
This connection can break down in many ways, but the detachment is often a conscious choice.
Many design methodologies advocate an 
analysis model
, quite distinct from the design and usually
developed by different people. It is called an analysis model because it is the product of analyzing
the business domain to organize its concepts without any consideration of the part it will play in a
software system. An analysis model is meant as a tool for understanding only; mixing in
implementation concerns is thought to muddy the waters. Later, a design is created that may have
only a loose correspondence to the analysis model. The analysis model is not created with design
issues in mind, and therefore it is likely to be quite impractical for those needs.
Some knowledge crunching happens during such an analysis, but most of it is lost when coding
begins, when the developers are forced to come up with new abstractions for the design. Then
there is no guarantee that the insights gained by the analysts and embedded in the model will be
retained or rediscovered. At this point, maintaining any mapping between the design and the
loosely connected model is not cost-effective.
The pure analysis model even falls short of its primary goal of understanding the domain, because
crucial discoveries always emerge during the design/implementation effort. Very specific,
unanticipated problems always arise. An up-front model will go into depth about some irrelevant
subjects, while it overlooks some important subjects. Other subjects will be represented in ways
that are not useful to the application. The result is that pure analysis models get abandoned soon
after coding starts, and most of the ground has to be covered again. But the second time around,
if the developers perceive analysis to be a separate process, modeling happens in a less disciplined
way. If the managers perceive analysis to be a separate process, the development team may not
be given adequate access to domain experts.
Whatever the cause, software that lacks a concept at the foundation of its design is, at best, a
mechanism that does useful things without explaining its actions.