In this comment, David asked about the relationship between Domain-Driven Design (first proposed in this seminal book ) and model-driven engineering. My (short) answer is to reproduce here what we say about this topic on our Model-Driven book. Keep in mind that I’m not an expert on Domain-driven design so feel free to send your corrections.
Domain-driven design (DDD) is an approach to software development based on two main principles:
- The primary focus of a software project should be the domain itself and not the technical details.
- Complex domain designs should be based on a model.
As such, DDD emphasizes the importance of an appropriate and effective representation of the problem domain of the system-to-be. For this purpose, DDD provides an extensive set of design practices and techniques aimed at helping software developers and domain experts to share and represent with models their knowledge of the domain.
Clearly, DDD shares many aspects with MDE. Both argue the need of using models to represent the knowledge of the domain and the importance of first focusing on platform independent aspects (using the MDA terminology) during the development process. In this sense, MDE can be regarded as a framework that provides the techniques to put DDD in practice (to model the domain, create DSLs that facilitate the communication between domain experts and developers if needed, etc.) .
At the same time, MDE complements DDD by helping developers to benefit even more from the domain models. Thanks to the model transformation and code generation techniques of MDE, the domain model can be used not only to represent the domain (structure,
rules, dynamics, etc.) but also to generate the actual software system that will be used to manage it.
This simple figure aims to highlight the different focus of each technique and how they can be combined together.
Domain-driven design plus model-driven engineering