Domain Driven Design vs Model Driven Architecture

Question

I am curious, what are the differences between Domain Driven Design and Model Driven Architecture? I have the impression they have certain similarities.

Could you enlighten me?

Thanks

Holly

It might help people answer this question if you could provide a little bit of background into the research you've already done. – Guideline

feel free to check this: youtu.be/MfEpw2WXXyk – Jacquesjacquet

Answer 1

Don't disagree with most of the above although it's perhaps worth expanding a little.

The single most important concept in DDD is to focus on the problem domain. To put technology obsession to the side and concentrate primarily on modelling the problem you're trying to solve. So put ajax, ORMs, databases, frameworks etc. into the background and instead make sure you have a complete, accurate model of the problem first and foremost. (Of course you still need the architectural components - but they're explicitly subservient to the model). DDD calls this "Ubiquitous Language" - a model expressed in terms domain experts and developers alike use and understand. A model where the names of classes, methods etc. are taken from the problem domain.

DDD doesn't mandate /how/ you capture that model, although the book implies using an OO language to do so.

MDA shares that same notion of modelling the problem domain first and foremost (the PIM, Platform-Independent Model). As opposed to DDD, it recommends creating that model with UML. But the intent is the same: understand the problem domain without tainting it with (software) architectural concerns.

MDA's PSM (Platform-Specific Model) is somewhat analogous to applying the architectural patterns in DDD (e.g. aggregate, repository, etc.). Again - while different in specifics - both aim to solve the problem of converting a 'pure' problem domain model into a full software system.

So summing up, I'd say they are similar in two ways:

1. The centrality of the Model (as @Rui says) - specifically the /Domain/ model.
2. Applying architectural patterns to the model in order to realise the target system.

hth.

Terriss

Answer 2

The root of both Domain-Driven Design (DDD) and Model Driven Architecture (MDA) is Model-Driven Engineering(MDE), also known as Model-Driven Software Development (MDSD) if limited to the software development domain. See Wikipedia: http://en.wikipedia.org/wiki/Model-driven_development

All approaches falling under the MDE umbrella have one thing in common: a model. How this model is materialized depends on the specific MDE flavor.

MDA is regarded as overly complex. DDD is considered by some as too abstract. My personal favorite MDE implementations are DSM and ABSE (not listed on the Wikipedia article).

Retrospection

Can you briefly elaborate on DSM and ABSE? – Actinomycin

DSM likely refers to Domain-specific modeling, which advocates the use of domain-specific modeling languages (basically DSLs used to describe domain models) which I also found very useful in certain cases. ABSE seems to be a concept invented by the author of this answer, see https://mcmap.net/q/339461/-are-you-doing-mda-model-driven-architecture-right-now-if-so-what-tools-do-you-use-and-how-is-it-working-out (as far as I can tell it's a research result, and probably not widely used or known in practice) – Soave

Answer 3

DDD is about approaching a software solution from a business perspective with the intent of keeping the design as much close to the real world as possible. This is more of an art than engineering.

MDA solves different set of problems. More details here: http://xml.coverpages.org/OMG-MDAFAQfinal1.pdf

Linlithgow

Engineering is an Art :) – Spanish

Answer 4

Each X-Driven approach helps deliver values of specific aspects and representations in problem-solving activities. From my point of view, the main difference is that DDD is a design technique and MDA is an infrastructure, which is needed when the engineering community wanted to use it in the real world industry.

The term of Domain in DDD has isA relationship to "Problem Domain" and often seems the same thing. DDD values domain expertise, where decision depends on how much we understand the problems and how we choose the right path from initial to winning states. Before the final design spec can be written, there will be a great effort on problem studies. By looking at the main 3 principles of DDD. I map DDD with things I familiar with my age nowadays, (a) Focus on the core domain (DDD & MVP seems identical in the focus setting), (b) Explore models in a creative collaboration (This is Model-Driven/Based Engineering). Two contributors consist of domain expert - designer and professional software developer. (c) Speak a ubiquitous language within an explicitly bounded context (Communicate using Domain-specific language and develop artifacts relevant to the problem domain)

By looking at the development collaboration of MDA and related standards, it is an infrastructure for the application of Model-Driven Engineering. This is the evolution of the software industry in supporting the way to describe a software system using models and demonstrates how we organize CIM/PIM/PSM models and artifacts. Many powerful modeling operations and tools such as model transformation, domain-specific modeling languages, and automated software engineering techniques are officially emerged with MDA

Severen