The term 'Model-Driven Design' is used both by the OMG's Model Driven Architecture community and by Eric Evans' Domain-Driven Design. What's the key difference between what each means by it, and why does the confusion matter in practice?
answer
- OMG MDA = formal + generated
- Evans DDD = hand-written + refactored together
- same term, different mechanism
- ubiquitous language vs QVT transformation
- mismatch risk when term travels across teams
basics
~10 sOMG's version means machines transform formal models into code automatically; Evans' Domain-Driven Design version means developers hand-write code that mirrors an evolving domain model — same name, very different amount of automation and formality.
solid answer
~50 sOMG's Model Driven Architecture uses 'model-driven' to mean the model is a formal artifact, UML and Meta Object Facility based, that automated tooling transforms through CIM to PIM to PSM to code, with the model as something closer to source code for a generator. Eric Evans' Domain-Driven Design uses 'Model-Driven Design,' a named practice in the book, to mean something much less formal: the code itself is written to directly express the domain model's concepts and ubiquitous language, refactored together with the model as understanding deepens, with no generation step at all — model and code are two views of the same understanding, kept aligned by hand. The confusion matters because a team told to do model-driven design might reach for heavyweight generative tooling when the codebase and culture actually calls for the lighter practice, or vice versa, leading to a costly tooling mismatch.
go deeper
Not expected to know this distinction in depth; recognizing that 'model-driven' can mean different things in different contexts is enough.
Should be able to state the core mechanism difference: automated generation in the MDA tradition versus hand-written code kept aligned by discipline in the Domain-Driven Design tradition.
Should be able to explain why the confusion causes real process mismatches across teams and give a concrete example of asking the right disambiguating question.
Should be able to deliberately architect a project that blends both traditions where appropriate, generation for structural or peripheral concerns, hand-written model-aligned code for core behavioral logic, and communicate the distinction clearly enough to prevent org-level tooling mismatches.
## Two traditions, one term Two distinct, well-established software engineering traditions use overlapping vocabulary for meaningfully different practices, and conflating them is a common and costly source of miscommunication on real projects. ## The MDA tradition: automated transformation The first tradition, **Model Driven Architecture (MDA)**, comes from the Object Management Group and formalizes 'model-driven' around automated transformation: a model, typically expressed in UML with the Meta Object Facility as its formal underpinning, is treated as an input to tooling that mechanically produces the next artifact in a chain — Computation Independent Model to Platform Independent Model to Platform Specific Model to executable code — ideally via a transformation language such as QVT. In this tradition, the model is closer to source code for a compiler than to a design sketch: its formality and precision are what make automated transformation possible at all. ## The Domain-Driven Design tradition: hand-written and refactored The second tradition is **Eric Evans' Domain-Driven Design**, where 'Model-Driven Design' is the title of a specific practice, and book section, that means something quite different in mechanism, even though it shares the underlying goal of keeping the model authoritative. In this tradition there is no generation pipeline: developers write code by hand, but the code's classes, method names, and structure are deliberately made to mirror the domain model's concepts, using the same vocabulary the domain experts use, the ubiquitous language. When the team's understanding of the domain improves, both the model, however it's represented, often just diagrams and glossaries rather than formal UML, and the code are refactored together, by hand, to reflect that improved understanding. The two stay aligned through continuous, disciplined developer effort and code review, not through mechanical transformation. ## The practical difference The practical difference this creates is enormous, even though both traditions would describe themselves as making the model the single source of truth. MDA's version requires investment in formal modeling notation, transformation tooling, and generator infrastructure, and pays off through automated consistency and potentially multi-platform retargetability. The Domain-Driven Design version requires no special tooling at all, just team discipline, and pays off through code that stays readable and intention-revealing to anyone who knows the domain, at the cost of that alignment being manually maintained and therefore more fragile to lapses in discipline, since nothing mechanically prevents the code from drifting away from the model's vocabulary the way a generator would. | | MDA's version | The Domain-Driven Design version | |---|---|---| | Mechanism | Automated transformation | Developers write code by hand; model and code refactored together | | Notation | UML with the Meta Object Facility | Often just diagrams and glossaries | | Investment | Formal modeling notation, transformation tooling, and generator infrastructure | Team discipline | | Pays off through | Automated consistency and potentially multi-platform retargetability | Code that stays readable and intention-revealing | ## Why the confusion is expensive The confusion matters concretely when it crosses team or organizational boundaries. - A manager or architect who read about model-driven design in an MDA context might mandate formal UML modeling and code-generation tooling for a team that's actually well served by the lighter practice, imposing significant process overhead for a project that never needed automated transformation in the first place. - The reverse mismatch also happens: a team that genuinely needs multi-platform code generation, say generating both a mobile client SDK and a server stub from one contract model, might under-invest in tooling because model-driven design, as they understood it from a Domain-Driven Design-influenced background, just meant writing clean code that mirrors domain vocabulary, missing the case where actual automated generation was the right tool. ## Evans chose this deliberately Evans himself was explicit about this distinction and its history in the Domain-Driven Design book: he deliberately chose not to build his Model-Driven Design practice around code generation or round-trip engineering tools, citing their poor track record, from CASE tools and early UML-generation tooling of the 1990s and 2000s, at staying synchronized on anything beyond simple, mostly-structural systems. His practice is a conscious, named alternative to the MDA-style approach for teams working on complex behavioral domains, not an accidental subset or simplification of it — recognizing that distinction is exactly what prevents a team from reaching for the wrong one of the two traditions when someone says they should be doing model-driven design.
- If a job posting says a team does 'model-driven design,' how would you figure out which tradition they mean before assuming?Ask directly whether there's a code-generation or transformation step involved, and whether the model is expressed in a formal notation like UML with tooling support, or whether it's closer to a shared vocabulary or diagram that developers keep in sync with hand-written code. The presence or absence of an actual generator is the clearest disambiguator.
- Could a team reasonably combine both traditions on the same project?Yes — it's common to use lightweight, Domain-Driven Design-style model-driven design for the core, behavior-heavy domain logic where hand-written code stays clearer and more flexible, while using generative modeling for peripheral, structurally repetitive concerns like generating client SDKs or database migration scaffolding from a contract. The key is being deliberate about which parts of the system get which treatment rather than assuming one term covers the whole system uniformly.
It's like two different professions both calling their core practice 'blueprinting' — one means a CAD file that a CNC machine cuts parts from automatically, the other means a hand-drawn sketch that a craftsman continually redraws and re-carves to match as the design evolves; same word, very different amount of automation behind it.
saying these in an interview costs you the question
- treats the two traditions as identical because they share the term 'model-driven'
- assumes 'model-driven design' always implies code generation
- can't name what actually keeps the model and code aligned in the non-generative version
- unaware that the ambiguity can cause real process or tooling mismatches on real teams