Eleven Dogmas of Model-driven

Development

Rafael Chavesrafael@abstratt.com - Twitter: @abstratt

http://abstratt.com/blog/

Enterprise Software is much harder than it should be, lack of separation of concerns is to

blame.

I

Domain and architectural/implementation

concerns are completely different beasts and should be

addressed separately and differently.

II

What makes a language good for implementation makes it

suboptimal for modeling, and vice-versa.

III

Domain concerns can and should be fully addressed

during modeling, implementation should be a

trivial mapping.

IV

A model that fully addresses domain concerns will expose gaps in requirements much

earlier.

V

A model that fully addresses domain concerns allows the

solution to be validated much earlier.

VI

No modeling language is more understandable to end-users than a running application (or

prototype).

VII

A single architecture can potentially serve applications

of completely unrelated domains.

VIII

A same application can potentially be implemented according to many different

architectures.

IX

Implementation decisions are based on known guidelines

applied consistently throughout the application,

and beg for automation.

X

The target platform should not dictate the development tools,

and vice-versa.

XI