Domain-driven design can be understood as writing code strictly according to the model so that the code can better express the design and fit the model with the actual system.

Many complex projects do attempt to use some form of domain model, but do not tie the code to the model closely. These projects develop models that may be used for exploration at the beginning of the project, but as the project progresses, these models become irrelevant or even misleading. All the effort spent on the model does not guarantee correct programming, because the model and the design are different.

The design and coding of the various parts of the software system should faithfully reflect the domain model so that there is a clear correspondence between the two. We should review and modify the model so that the software can more naturally implement it, even when we want the model to reflect deeper domain concepts. We need a model that not only meets these two requirements, but also supports a robust UBIQUITOUS LANGUAGE.

If the person writing the code doesn’t feel responsible for the model, or doesn’t know how to make it work for the application, then the model has no relevance to the program. If developers don’t realize that changing the code means changing the model, their refactoring of the program can actually weaken the model rather than enhance it. Similarly, if the modeler is not involved in the implementation process, the constraints of the implementation are not personally felt, and if they are, they are quickly forgotten. One of the two fundamental elements of Model-driven DESIGN — that the MODEL supports an effective implementation and abstracts key domain knowledge — has been lost, and eventually the MODEL is no longer practical. Finally, if division of labor prevents designers and developers from communicating the details of implementing Model-driven DESIGN, then experienced designers cannot transfer their knowledge and skills to developers.

Therefore:

Any technical person involved in modeling, regardless of their primary responsibility on the project, must take the time to understand the code. Anyone responsible for modifying the code must learn to express the model in code. Every developer must participate in model discussions and liaise with domain experts to varying degrees. People involved in different efforts must consciously exchange ideas about the model in real time with people touching code through UBIQUITOUS LANGUAGE.