11 Dogmas of model driven development

Preview:

DESCRIPTION

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.

Citation preview

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

Recommended