View source for BestPractices:Model Driven

There are a lot of acronyms out there. This post will set things straight on how we, at MDriven, define these and how we use them.

== '''MDA – Model Driven Architecture''' ==
The idea that the model for an information system can be described in a platform independent format (''PIM''), and that the PIM can be transformed into artifacts that build up vital parts of the resulting IT-solutions. We at MDriven are currently geared towards the .net arena and we have no ambition to be platform independent with our MDA-Framework ECO. However, we see the benefit for all organizations to develop PIMs in order to secure their definitions in a longer perspective. Using the PIM approach, the investment for information design is safeguarded against shifts in technology. Our solution to PIM-production is the Modlr UML design tool. Modlr is part of both the ECO-designtime-Visual-Studio-plugin and the standalone model-and-execute tool AppComplete.
* ECO allows for applying the PIM in the UI layer by transforming it into ViewModels that in turn can be transformed into user controls for different UI architectures; WPF, ASP.NET, Windows forms and Silverlight. 
* ECO can apply the PIM result in Handles designed for different UI architectures; WPF, ASP.NET, Windows forms and Silverlight 
* ECO can transform the PIM into c#, VB.NET or Delphi.NET code (code generation) 
* ECO can transform the PIM into relational database schemas for SQLServer, Oracle, MySql and many more 
* ECO can put the PIM to use on a server to act as a OR-mapper for other PIM compliant services

== '''MDD – Model Driven Development''' ==
The idea to focus development efforts on a model and using the model as core definition and template for the rest of the artifacts needed for the finished product. Changes always go into the model first and then trickle down to the derived artifacts. The artifacts may be largely derived by an automated process (code generation, db schema generation) but could just as well be hand made. The gain in production speed and quality is largely omitted if you use the hand made approach.

ECO is model centric. Changes go into the model first, you then update the code, keeping your handwritten additions to the largely generated domain layer by utilizing partial classes. ECO also use the re-engineering capabilities of Visual Studio to apply changes done in the model thru out your code. The database schema is updated by a built in evolve function that use as non intrusive methods as possible on your existing database to change it from the original form to the form that  is described by the model.

== '''DDD – Domain Driven Design''' ==
The idea that the model should adhere to the terms and definitions from the domain the system is built for. To many of us that have been modeling business for many years this is kind of a no brainer; how would you do it any other way? But think about it like this: We can understand the domain very well but still choose to model it with abstract and non domain specific names. Maybe in an effort to create a reusable model for other domains with the same need, or maybe in an attempt to create an optimized version of the domain. That model can be still be used with MDA and MDD but it would not be DDD. DDD aims to create an ubiquitous  language between developers, modelers, domain experts and stakeholders, and thus taking the technical mumbo jumbo out of creating IT-systems.

ECO is great for DDD. We have not done anything extra for making it a good DDD tool apart from making it a super MDD and MDA tool. DDD is describing the mindset you have while modeling and not really saying anything on how to use the model once you are done.
[[Category:Architecture]]