Tools (Best Practices?) for model driven development?

Model Driven Software Development.

As I understand it it raises the abstraction level of the design to better reflect the domain the software will attempt to run in. That's alot to say in just one sentence.

The communication between the domain experts (customer) and the developers is crucial to make this methodology work. What I want to know is if there is a tool suite or set of best practices that will help in the initial thrust of MDSD? Once the domain is fleshed out what about mapping that model to an ORM (or whatever)?

I am just diving into the realm of MDSD and DSL so any constructive ideas or comments will be appriciated.

From stackoverflow

• if you are programming in .net you should read "Applying Domain Driven Design and Patterns" by Jimmy Nielsson. He also has a section on ORM (NHibernate), SOA and Dependency injection.

  In any case you should take a look at "Domain Driven Design" by Eric Evans. It's a classic where you can find invaluable information about patterns and best practices for domain driven design

• If you are developing on Microsoft platforms, you might want to check out Oslo also. There is a nice overview here: http://www.pluralsight.com/community/blogs/aaron/archive/2008/11/03/introducing-quot-oslo-quot.aspx

  Here's a ton of links from Chris Sells: http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=2197

  I am not ready to equate Domain Driven Design with Model Drive Development just yet.

  You might also want to check out Model Driven Architecture (the OMG MDA) for perspective though probably not much on rolling your own.

  A big issue in Model-driven-anything has to do with where the expertise comes from that derives implementations from models and what level maintenance (and debugging) happen at. My test of available books would be how they make the pipeline understandable and how well one can comprehend the path from modeling through deployment and back again.

  jbandi : Exactly! MDSD and DDD are something different! They are often lumped together. On a high level they have similar goals, but the means to reaching those goals have completely different priorities!

• Disclaimer: I am a developer of business applications. The following view is certainly shaped by my experiences in trenches of enterprise IT. I am aware, that there are other domains of software development. Especially in industrial and/or embedded systems development the world might look different.

  I think MDSD is still too much tied to code generation.

  Code generation is only useful, when your code contains a lot of noise and/or is very repetitive. In other words, when your code can not mainly focus on the essential complexity, but is polluted with accidental complexity.

  In my opinion the trend in current platforms and frameworks is exactly to remove accidental complexity and letting the application code focus on essential complexity.

  So these new platforms/frameworks take a lot of the wind out of the sails of the MDSD movement.

  DSLs (textual ones) are another trend that tries to enable the sole focus on essential complexity. While DSLs can be used as source for code generation, they are not primarily tied to code generation. DSLs (especially internal DSLs) basically let it open to be interpreted/executed at runtime. [runtime code generation is somewhere in between].

  So even if DSLs are often mentioned together with MDSD, I think they are really an alternative to MDSD. And given the current hype, they also take the momentum out of the MDSD movement.

  If you have reached the goal of ultimately removing accidental complexity out of your code (I know this is fictitious), then you have arrived at a textual model of your business problem. This cannot be further simplified!

  Nice boxes and diagrams do not offer another simplification or elevation of the abstraction level! They may be good for visualization, but even that is questionable. A picture is not always the best representation to grasp complexity!

  Further more, the current state of the tooling involved in MDSD adds another level of accidental complexity (think: synchronization, diffing/merging, refactoring ...) which basically nullifies the ultimate goal of simplification!

  Look at the following ActiveRecord model, as an illustration of my theory:

  class Firm < ActiveRecord::Base
     has_many   :clients
     has_one    :account
     belongs_to :conglomorate
  end
  

  I dont think that this can be any more simplified. Also any graphical representation with boxes and lines would be no simplification, and would not offer any more convenience (think about layouting, refactoring, searching, diffing ...).

  Roland Tepp : Although I like your answer I'd point out that frameworks that remove the accidental complexity, as you put it, still do not abstract away the implementation detail. Model object in RoR is only useful in the context of that framework. You can't derive .NET, Java or C++ implementation from that alone

  jbandi : @Roland You are completely right. Just in my experience (custom enterprise applications) it is hardly a requirement to be platform agnostic. I think portability/platform independence is often an overrated "ivory-tower feature" that is not needed in reality...

• MDD can be really complex or relatively simple.

  If you want to automate transformation from your various models (in UML, for example) to code and do round-trip engineering and all that, you can get some pretty fancy tools.

  Or

  You can draw the models and build the code more-or-less by hand, using a one-way (model to code) transformation.

  The idea of building a model first is a well-established best practice. It's often called "design". The problems arise when people conflate design with specification. The model of what will be built is not a programming specification. It's an abstraction that can be used for evaluating correctness, defining test cases, writing specifications, etc.

  You don't have to model everything. You can start MDD by having a data model -- independent of any specific implementation.

  1. You draw your model using UML.

  2. You transform the UML to class definitions.

  3. You use an ORM layer (or ODBMS) to map your models to some kind of storage.

  You don't need a lot more than this. What you do need to do is focus on getting the model right before you tackle too many other issues.

  The issues usually arise from all kinds of premature optimization that happens during software development. Early leaps into RDBMS physical design. Early leaps into web page design and using that to drive the data model. Early leaps into defining the server architecture and allocating storage.