Core MDD Principles

## The artifact of record In most software projects, 'the model' shows up as a UML diagram in a wiki page, drawn during initial design and never opened again. **Model-Driven Design rejects that pattern.** It insists the model — a structured representation of the important concepts, their relationships, invariants, and behavior — is the artifact of record: the thing developers, testers, and business stakeholders treat as authoritative when they disagree about what the system does. Code, database schemas, and API contracts are expected to be derived from or kept faithful to the model, not the other way around. ## Two flavors Mechanically this plays out in two flavors. 1. **The heavyweight version is generative.** Tooling (in the OMG's Model Driven Architecture tradition, using UML plus the Meta Object Facility) reads a formal model and produces skeleton code, database DDL, or even a fully executable system, so the model is quite literally compiled. 2. **The lighter, more common version** — closer to Eric Evans' Domain-Driven Design usage of the term 'model-driven design' — **is disciplinary rather than mechanical.** There is no generator, but the team enforces that every class, method, and table name traces back to a concept in the model, and every model change forces a corresponding code change in the same commit. | Flavor | What keeps the code faithful | |---|---| | Generative, heavyweight | Tooling reads the formal model and produces the code | | Disciplinary, lighter | The team enforces that every name traces back to a concept in the model | Both flavors share the same goal: **eliminate the gap between what was designed and what was built.** ## The translation gap The problem this solves is an old one — the **translation gap**. A business analyst writes a spec, an architect draws a diagram interpreting the spec, and a developer writes code interpreting the diagram; at each hop, information is lost or silently reinterpreted, and six months later nobody can say with confidence what the system is actually supposed to do, because the diagram — if anyone still has it — no longer matches the code. Making the model the primary artifact collapses those hops: there's one representation that must stay true, and everything else answers to it. ## The trade-off: discipline versus speed The trade-off is discipline versus speed. Keeping a model authoritative costs continuous maintenance effort — every schema tweak, every new business rule, has to be reflected in the model as well as the code, and code reviews have to check for drift, not just correctness. Teams under deadline pressure routinely let this slip: - a developer patches the generated code directly to hit a deadline, or - adds a field to a table without updating the corresponding model element. In generative setups this is sharper still, because hand-edited generated code gets silently overwritten the next time someone regenerates from the model — the classic **round-trip engineering** failure mode; teams work around it with generator 'protected regions' or by abandoning generation for hand-written code that merely mirrors the model's vocabulary. ## What it cashes out to day-to-day A concrete real-world instance: shops using Domain-Driven Design tactically keep an aggregate concept — say, an `Order` with its `OrderLine` children — as the model, and insist that - the `Order` class in code, - the `orders` and `order_lines` tables, and - the API's `Order` DTO all use exactly that vocabulary and exactly that consistency boundary, with no helper classes carrying logic the model doesn't describe and no direct SQL updates to `order_lines` that bypass the `Order` aggregate's invariants. That discipline is what 'model as primary artifact' cashes out to day-to-day: not a diagram, but a standing rule that code must justify itself against the model, and the model must justify itself against the domain. ## How it fails Failure shows up gradually rather than as an outage: - new hires read the stale model and build features that contradict how the code actually behaves; - two teams implement the 'same' concept differently because each trusted a different stale copy of the model; - and eventually the model is quietly deleted from onboarding material because 'it's wrong anyway' — at which point the team has reverted to code-only design with all the translation-gap risk that model-driven design was meant to remove.