Model-Driven Design

An internal DSL is written using the normal syntax of an existing programming language, just arranged to read like a mini-language for one job (e.g. a Kotlin build script). An external DSL has its own custom syntax and needs its own parser to be understood, like SQL or a regular expression.

MDA is a way of building software by first drawing a model of what the system does, ignoring the technology, then turning that model into one tied to a specific technology (like Java or a database), and finally generating code from it.

Forward engineering writes the model first, then a tool generates code from it. Reverse engineering starts from existing code and builds or updates a model to describe it. Same goal—keep model and code matching—different starting point.

Model-to-text turns a model into plain text, like source code, mostly a one-way trip. Model-to-model turns one structured model into another structured model, so it stays machine-readable and can be transformed again.

They're three levels of the same design, from business-language description (CIM), to a tech-neutral system design (PIM), to a version tied to one specific technology (PSM) — each layer adds detail the previous one deliberately left out.

The grammar is a set of rules describing what a valid sentence in your mini-language looks like, similar to a sentence-structure rule like 'an order has a customer name and a list of items.' Tools like Xtext turn that grammar into both a parser and an in-memory data model, and then automatically generate editor features like syntax highlighting and autocomplete from the same rules.

MOF is a stack of four levels, like Russian nesting dolls: M0 is the real data at runtime, M1 is a model of it (like a UML diagram), M2 is the language used to draw that diagram (UML's rules), and M3 is the top rule-set (MOF) that even defines UML's own rules and defines itself.

Instead of a separate diagram file, you put small tags (annotations) right on the code, like @Entity on a class. A tool reads those tags to generate the model (like a database schema or API spec), so the model and code can never drift apart—they're the same file.

Mark off areas in the generated file as 'protected' or split hand-written code into a separate file the generator never touches. Round-trip engineering is about letting generated output and manual edits coexist without one wiping out the other.

Template-based generation fills in text templates that look like the output, with holes for model data. Rule-based generation runs a set of if-this-then-produce-that rules that decide what to build. Templates are easier to read; rules scale better for complex mappings.

When developers change code without updating the model, or vice versa, the model stops being trustworthy — new features get built on wrong assumptions, and fixing it usually means a deliberate re-sync project rather than something that happens automatically.

Scope rules decide which named things - like another element defined elsewhere - are visible and can be referenced from a given point in the file, similar to how you can only use a variable after it's declared. Getting this wrong makes autocomplete suggest the wrong things or 'go to definition' silently jump to the wrong place.

PIM and PSM are both just models sitting at the same level in the stack, built using rules like UML's. A transformation tool reads the PIM according to those rules and writes out a PSM according to a possibly different set of platform rules, using a defined mapping between the two.

You can automatically compare the model against the real code—like checking that every class the diagram shows still exists, and no new dependency was added that the diagram doesn't show—and fail a build or flag a warning when they don't match, instead of just hoping someone notices.

Leaking means details from a lower, more technical layer sneak into a higher, supposedly technology-neutral layer, like a database-specific trick showing up in the 'business' model, which defeats the whole point of keeping them separate.

Pick internal if the authors are your own developers and you want low build cost with full access to the host language. Pick external if you need a stricter, safer, or non-programmer-friendly notation. Picking wrong means either wasting months on a parser nobody needed, or handing power users a dangerously open language when a safe sandbox was required.

UML's own rules, like what a Class or Association is, are written using MOF's building blocks. If you just need to tag extra info onto UML diagrams, you use a lightweight Profile, like stickers on a form. If you need a whole new kind of diagram with its own rules, you define a brand-new metamodel instead.

The tool has to remember which parts of the code were auto-generated and which parts a person wrote by hand, every time it regenerates, so it doesn't delete a developer's custom logic. Keeping that separation correct through many edit cycles is the hard part.

An executable model is run directly by an interpreter that reads the model and carries out its behavior on the spot, like a script. A generative model is instead used as a blueprint to produce other code, such as Java or SQL, which is then compiled and run separately. Executable is more immediate; generative gives you inspectable, tunable output code.

A good two-way sync tool must guarantee that going model→view→model (or the reverse) lands back exactly where you started, which is much harder to prove than just writing 'convert A to B' and separately 'convert B to A' by hand, because the two halves can quietly disagree. If changes are rare or one side is clearly authoritative, it's often not worth the complexity.

Full generation regenerates everything from the model every time, which only works if the model truly captures 100% of the system's logic. Partial generation, generating only the repetitive, well-understood parts (like data access boilerplate) and hand-writing the rest, is far more common because most real systems have logic that's awkward or impossible to fully model.

Declarative transformation rules say what relationship must hold between source and target, and let the engine figure out how to make it happen. Imperative rules say exactly what steps to run. Declarative is easier to reason about and check consistency; imperative gives more control for tricky, order-dependent logic.

When the project is small, the platform won't change, or the domain is still being figured out — the cost of building and maintaining formal layered models and generators outweighs any benefit, and a lighter, code-first approach ships faster and adapts better.

Building and maintaining the models, transformation rules, and generators cost more than most teams ever got back, because most software only ever targets one platform and changes more through new features than through swapping technology — so the insurance MDA sold rarely paid out. It's worth it mainly for large, long-lived systems that genuinely target multiple platforms or where regulators demand traceable models.

Over years, the transformation rules and templates themselves become their own hard-to-maintain codebase, generated and hand-written code quietly drift apart, and fewer people understand how the pipeline works. It stops being worth it once the generator's upkeep costs more than just writing the code directly.

OMG'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.

Graphical DSLs, diagrams you drag and connect, work well when the domain is naturally visual with a small, stable set of elements per screen, like state machines or flowcharts. They get unwieldy for anything with lots of detail, like complex logic or large data structures, where text is faster to write, search, and compare between versions.

Instead of throwing away and rebuilding the whole target model every time the source changes even slightly, TGGs figure out just the small piece that actually needs to update, using pre-defined pattern rules—like patching instead of rewriting. The cost is that you must formally define every allowed pattern up front, which is a lot of specialized modeling work.