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 in 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
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
David wrote:
I agree that that seems to be the case. My opinion is that it is not just out of sheer obliviousness from both sides, but more due to important cultural differences. Many people in the MDD camp have somewhat an ivory tower mindset, whereas DDD folks are very pragmatic.
Incidentally, I believe I am part of this small intersection of DDD and MDD enthusiasts. I am a fan of language supported domain-driven design, and that is what attracted me to model-driven development, more specifically through executable modeling. While I like the higher level abstraction and separation of concerns that MDD provides over using ordinary programming languages, I am not interested in modeling if it does not lead to code that not only is fully functional (as opposed to partial), and which looks as good as code written by competent developers (as opposed to obviously machine generated).
As originally authored, DDD calls for the domain problem under consideration to be represented as an OBJECT model. DSLs and tools that might (help) generate that model are entirely consistent with that view.
Unfortunately, object modeling in a web focused world where concepts are first modeled as DATA concepts (typically a relational data model) modified by separate code modeled using functional decomposition, means that DDD has become something other as originally described in the Evans book.