Friday Jun 22, 2007
Model-Driven Engineering (MDE)
This evening it looked to me as if the whole software engineering community got enchanted by MDE (model-driven engineering) and DDD (domain-driven design) during the last six months. Not only was my current project more or less forced to use DDD (after reading the mandatory DDD bible by Evans, of course), but also the subject of the presentation I attended this everning was all about MDE.
A student from the Technical University Delft gave a very good and clear presentation on domain modelling tools or, as he preferred to call it, domain editing tools. One of his first slides finally revealed to me the whole intention/motivation behind this MDE:
Clearly your development (and maintenance) can in principle benefit a lot from a clear, ubiquitous and semantically meaningful principle underlying the class definitions (i.e. objects) used in the implementation of your application, namely the concepts that constitute the very business domain you are modelling. The central theme of his talk could very well be summarized by the slogan "a good implementation resembles its design". Bearing the MDE and DDD paradigms in mind, the problem statement was formulated as follows:
Of course, this principle is far from new, as it is a modern version of Donald Knuth's literate programming. The more remarkable it actually is that still so many IDEs still revert to store their UML models in a file separate to the source code, which inherently induce synchronization issues. An additional complication here is the fact that the domain is only part of the implementation. Obviously we would like to have a mapping: business domain <=> implementation language <=> IDE (integrated development environment). This mapping should always be in sync at all three "levels".
Focusing in on this problem, we can observe an impedance mismatch between the Java (i.e. implementation language) and domain levels:
In particular, for the bi-directional coupling between the domain model and the Java language we observe:
A first prototype that addressed all these issues, based on Eclipse 3.3 (!) and Hibernate annotations, was demonstrated during the presentation:
Last but not least my long lasting question was also answered whether MDE was the paradigm of choice for every project. As could be expected (since "one size fits all" seems to be a bad idea anyhow), DDD only pays off when the business layer is appropriately complex and tooling supporting MDE is mature and available.
This answer confirmed my doubts with respect to the use of DDD principles in a project that merely entails the display of data coming in from a web services based back-end. And then we did not even address the issue of the intricate relations between entities and repositories that may result when implementing lazy loading, see also "Refactoring our way to glory: An exercise in implementing a domain-driven design" (recommended!).