11 Dogmas of Model-Driven Development

I prepared the following slides for my Eclipse DemoCamp presentation on AlphaSimple but ended up not having time to cover them. The goal was not to try to convert the audience, but to make them understand where we are coming from, and why AlphaSimple is the way it is.

And here they are again for the sake of searchability:

I – Enterprise Software is much harder than it should be, lack of separation of concerns is to blame.

II – Domain and architectural/implementation concerns are completely different beasts and should be addressed separately and differently.

III – What makes a language good for implementation makes it suboptimal for modeling, and vice-versa.

IV – Domain concerns can and should be fully addressed during modeling, implementation should be a trivial mapping.

V – A model that fully addresses domain concerns will expose gaps in requirements much earlier.

VI – A model that fully addresses domain concerns allows the solution to be validated much earlier.

VII – No modeling language is more understandable to end-users than a running application (or prototype).

VIII – A single architecture can potentially serve applications of completely unrelated domains.

IX – A same application can potentially be implemented according to many different architectures.

X – Implementation decisions are based on known guidelines applied consistently throughout the application, and beg for automation.

XI – The target platform should not dictate the development tools, and vice-versa.

I truly believe in those principles, and feel frustrated when I realize how far the software industry is from abiding by them.

So, what do you think? Do you agree these are important principles and values? Would you call B.S. on any of them? What are your principles and values that drive your vision of what software development should look like?

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

9 thoughts on “11 Dogmas of Model-Driven Development

  1. Pierre-Charles David

    September 29, 2011 at 12:32am

    You might want to name these principles something else that “dogmas”; that name evoques strong beliefs held by people even if they contradict facts. Indeed, Wikipedia says: “Dogma is the established belief or doctrine held by a religion [...]. It is authoritative and not to be disputed, doubted, or diverged from, by the practitioners or believers.” Is that the idea you want to convey?

    How about simply “11 principles of MDD”, or “11 lessons learned from MDD” (if you justify them from concrete experience)?

  2. Steven Kelly

    September 29, 2011 at 2:17am

    Good set, although clearly only focused on enterprise software.

    I’d disagree with III and VII, although it’s probably just a question of how you’ve expressed them.

    “III – What makes a language good for implementation makes it suboptimal for modeling, and vice-versa.”

    A good Domain-Specific Modeling Language is great for implementing in. Implementing just means “what you need to do to write one more application”. Of course there are generators and frameworks under the hood of a DSML, but that’s true also for languages that you’re considering ‘implementation languages’.

    I wonder if a truer version would be “what makes a language good for a particular domain is what makes it suboptimal as a general purpose language, and vice versa”.

    “VII – No modeling language is more understandable to end-users than a running application (or prototype).”

    I’d disagree. A good model of structure, states or UI flow allows you to see the whole application at once, whereas using the application means you have to spend extra time pushing the buttons, and only see a small piece at once. That’s why we provide documentation to end users, often showing structure or flowcharts.

    Clearly though the ideal is the combination of both. I’d argue that such a combination is also the best thing for the developer, so he can go quickly from adding a bit in the model to testing that in the running application.

  3. Federico Tomassetti

    September 29, 2011 at 2:51am

    Great post, I fully agree.

  4. Nikola Tankovic

    September 29, 2011 at 4:05am

    Excellent summary! A true separation of concerns!

  5. Jeroen van den Bos

    October 3, 2011 at 6:57am

    Why do you state that implementation should be a “trivial mapping”? Perhaps I misunderstand your point, but sometimes the power of a model-driven solution is in the intermediate transformations it performs going from model to implementation, shielding the modeler from these complicated and often domain-specific details.

  6. rafael.chaves

    October 4, 2011 at 10:43pm


    The trivial mappings I refer to is exactly the kind of transformation model-driven tools perform. They may seem complicated to a non-technical user, but for developers that know how to do it, they are utterly boring and repetitive. Automation, by taking care of the non-intellectually challenging work, allows developers to focus on getting the domain model right, which is what matters most anyways.

    Does that make sense now?

  7. Ken Lyle

    November 7, 2011 at 4:49pm

    Very nice. I like it even better with Steven Kelly’s refinements.

Comments are closed.