Technology weblog

IT-Essence
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:

Reduce maintenance and development by working on the model instead of the code level

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:

Can the implementation hold enough information to act (at the same time) as modelling language?

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:

 JavaDomain
- Types
- Entities
- Repositories
- Factories
- Services
- VOs
- Aggregates
- Fields
- Methods
- properties
- Projects
- Packages
- modules

In particular, for the bi-directional coupling between the domain model and the Java language we observe:

  • Refactoring: refactoring of your code according to manipulations of the domain model.
  • Modelling: reverse engineer domain information from Java code.

A first prototype that addressed all these issues, based on Eclipse 3.3 (!)  and Hibernate annotations, was demonstrated during the presentation:

  • The "@entity" tag was used to "signal" an entity
  • A plug-in was developed that extracted the domain information from the code and generated a domain model diagram.
  • The generation of this diagram takes place during compilation so no external model file needs to be stored nor maintained. Moreover, this way the model is always in sync with the code.
  • Changes in the code were shown to be propagated to the model and vice versa.

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!).

Comments:

Post a Comment:
Comments are closed for this entry.

Hire us
Archives
Tags
Links
Stats
Referrers