Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ElevenDogmas of Model-driven Development Rafael Chaves rafael@abstratt.com - Twitter: @abstratt http:...
I Enterprise Software is muchharder than it should be, lackof separation of concerns is to blame.
II Domain and architectural/implementation concerns are completelydifferent beasts and should be addressed s...
IIIWhat makes a language good for implementation makes itsuboptimal for modeling, and vice-versa.
IV Domain concerns can and should be fully addressed during modeling,implementation should be a trivial mapping.
VA model that fully addressesdomain concerns will expose gaps in requirements much earlier.
VIA model that fully addresses domain concerns allows thesolution to be validated much earlier.
VIINo modeling language is more understandable to end-usersthan a running application (or prototype).
VIII A single architecture canpotentially serve applications of completely unrelated domains.
IX A same application canpotentially be implementedaccording to many different architectures.
XImplementation decisions are based on known guidelines applied consistently throughout the application, and beg for...
XIThe target platform should notdictate the development tools, and vice-versa.
Upcoming SlideShare
Loading in …5
×

11 Dogmas of model driven development

7,198 views

Published on

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


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

Published in: Technology
no profile picture user

  • Login to see the comments

11 Dogmas of model driven development

  1. 1. ElevenDogmas of Model-driven Development Rafael Chaves rafael@abstratt.com - Twitter: @abstratt http://abstratt.com/blog/
  2. 2. I Enterprise Software is muchharder than it should be, lackof separation of concerns is to blame.
  3. 3. II Domain and architectural/implementation concerns are completelydifferent beasts and should be addressed separately and differently.
  4. 4. IIIWhat makes a language good for implementation makes itsuboptimal for modeling, and vice-versa.
  5. 5. IV Domain concerns can and should be fully addressed during modeling,implementation should be a trivial mapping.
  6. 6. VA model that fully addressesdomain concerns will expose gaps in requirements much earlier.
  7. 7. VIA model that fully addresses domain concerns allows thesolution to be validated much earlier.
  8. 8. VIINo modeling language is more understandable to end-usersthan a running application (or prototype).
  9. 9. VIII A single architecture canpotentially serve applications of completely unrelated domains.
  10. 10. IX A same application canpotentially be implementedaccording to many different architectures.
  11. 11. XImplementation decisions are based on known guidelines applied consistently throughout the application, and beg for automation.
  12. 12. XIThe target platform should notdictate the development tools, and vice-versa.

×