MDD — Model Driven Development

Движущая сила: модель — формальное абстрактное описание системы; код рассматривается как производное, а не первичный артефакт.

Уровень применения: организация и архитектура (требует зрелых инструментов, стандартов и дисциплины моделирования).

Статус: устоявшийся, но нишевый (OMG Model Driven Architecture, 2001); возрождается в виде low-code-платформ и AI-генерации из формальных спецификаций.

Не путать с: Model-First (разовое проектирование модели перед кодом), Low-Code/No-Code (продуктовая категория платформ), и с современным «AI-driven» (AIDD) — разведение см. в разделе «Связанные подходы».

Общее #

Model Driven Development (MDD) — зонтичный подход к разработке ПО, в котором первичной движущей силой выступает модель — формальное, абстрактное описание системы, выраженное на языке моделирования (UML, SysML, BPMN, специализированный DSL). Модель здесь не иллюстрация к коду и не постфактум-документация, а первичный артефакт: код, конфигурация, схема базы данных, тесты и развертывание рассматриваются как производные модели, получаемые через цепочку трансформаций. Ключевой тезис MDD: повышение уровня абстракции, на котором ведётся основная инженерная работа, — от строк кода к моделям — позволяет переиспользовать одну и ту же модель для нескольких платформ, автоматизировать рутинный бойлерплейт и сделать архитектуру явным, проверяемым артефактом.

Подход был институционально оформлен Object Management Group (OMG) как Model Driven Architecture (MDA) в 2001 году. MDA — конкретное воплощение MDD, в котором вводится три уровня моделей и специфицируются правила перехода между ними: CIM (Computation Independent Model — модель, независимая от вычислений; бизнес-видение), PIM (Platform Independent Model — модель, независимая от платформы; логическая архитектура) и PSM (Platform Specific Model — модель, зависимая от платформы; привязка к технологическому стеку). От PSM код генерируется автоматически или полуавтоматически. Терминология CIM/PIM/PSM стала де-факто словарём MDD даже за пределами строгого MDA. Сама идея модельно-ориентированной разработки старше OMG: её корни — в CASE-инструментах и методологиях 1980–1990-х (Structural Analysis, OMT, Booch), где код предполагалось генерировать из диаграмм. MDA собрал разрозненные практики в связный стандарт с собственным метамодельным фундаментом (MOF — Meta Object Facility).

Принципиальное отличие MDD от остальных «*DD» в этой серии — степень абстрактности движущей силы. Если в TDD дизайн направляют исполняемые тесты, в DDD — модель предметной области, в BDD — сценарии поведения, а в FDD — фича как единица доставки, то в MDD движущая сила — абстрактная формальная модель, из которой механически выводится код. Отсюда принципиально иной цикл работы: не «пиши код → проверяй», а «спроектируй модель → трансформируй → сгенерируй код → синхронизируй». Инженерная работа сдвигается вверх по жизненному циклу — на уровень моделирования, — а кодогенерация становится механической. Это делает MDD прежде всего организационно-архитектурным подходом, чувствительным к зрелости инструментов и к дисциплине команды.

Ключевые принципы #

MDD — это не «нарисовать UML перед кодом» (это — Model-First), а набор принципов, которые в совокупности превращают модель из иллюстрации в первичный артефакт. Ниже — формулировка каждого с пояснением, какую конкретную проблему он решает.

Модель первична (model as single source of truth). Модель — единственный источник истины для системы; код, тесты, конфигурация и документация выводятся из неё и считаются производными. Проблема: в классической разработке модель (диаграммы, документация) и код расходятся после первого релиза — диаграммы устаревают, а код становится фактической спецификацией; каждое «перевод» между ними — точка потери смысла. Объявление модели первичным артефактом делает расхождение дефектом процесса, подлежащим устранению: изменили код — должны изменить модель, и наоборот.

Разделение PIM и PSM. Архитектура описывается на двух уровнях: платформо-независимая модель (PIM) фиксирует логику системы безотносительно к технологии, а платформо-зависимая модель (PSM) привязывает эту логику к конкретному стеку (JPA + Spring, .NET + EF, Node.js + TypeScript). Проблема: смешение бизнес-логики и инфраструктурного кода в одном слое приводит к тому, что миграция на новую платформу или поддержку нескольких платформ приходится делать вручную, переписывая значительную часть системы. Разделение PIM/PSM делает переносимость явным свойством модели: одна PIM → несколько PSM → несколько целевых стеков.

Трансформации моделей (model transformations). Переход между уровнями моделей (CIM→PIM, PIM→PSM) и от PSM к коду описывается явными, повторяемыми правилами трансформации, а не выполняется вручную. Трансформация — это программа, которая читает исходную модель и порождает целевую (или код). Проблема: ручное «перекладывание» модели в код — это медленный, ошибкоёмкий и неповторимый процесс; каждое изменение модели требует ручного же изменения кода. Формализованные трансформации делают вывод кода механическим, повторяемым и версионируемым артефактом.

Исполняемые модели (executable models). Модель, по возможности, должна быть не только описательной, но и исполняемой — то есть достаточно формальной, чтобы её поведение можно было проверить (симулировать) до генерации кода. Проблема: диаграмма на бумаге или в Visio не проверяема — её корректность устанавливается только глазным ревью, а дефекты логики всплывают уже в коде. Исполняемая модель (через action language, constraint-языки типа OCL, или симуляторы) сдвигает обнаружение дефектов логики на уровень модели, где исправление дешевле.

Обратная синхронизация (round-trip engineering). Идеальный цикл MDD — двунаправленный: изменения в модели порождают изменения в коде, а изменения в коде (сделанные вручную) обратно синхронизируются с моделью. Проблема: односторонняя кодогенерация («модель → код, и точка») ломается при первом же ручном правке кода — модель и код расходятся, и подход вырождается в классическую разработку с устаревшей диаграммой. Round-trip engineering задуман как лекарство, но на практике он — самое слабое место MDD (см. «Недостатки и риски»).

Стандартизация языков моделирования. MDD опирается на стандартизованные языки (UML, SysML, BPMN, XMI для обмена) или на явно определённые DSL — а не на ad-hoc нотации команды. Проблема: команда, использующая собственную «псевдо-UML», не может ни переиспользовать сторонние трансформации, ни обменяться моделью с другой командой, ни опереться на зрелые инструменты. Стандартизация делает модели переносимыми между инструментами и накапливаемыми между проектами.

Инструменто-зависимая дисциплина. В отличие от TDD, где инструмент минимален (тест-раннер), MDD неработоспособен без зрелого инструментального стека: редактор моделей, репозиторий моделей, движок трансформаций, генератор кода, синхронизатор. Проблема: слабый инструмент делает MDD-theatre — модели рисуются, но код пишется вручную, а «генерация» — косметический шаг. Полноценное MDD-внедрение означает инвестицию в инструменты и в их настройку под домен.

Принципы — система, а не меню. Модель без трансформаций превращается в иллюстрацию; трансформации без разделения PIM/PSM не дают переносимости; PIM без исполняемости проверяется только в коде; исполняемость без round-trip ломается при первом ручном правке. Частичное внедрение создаёт фасад: модели рисуются «для отчётности», а код пишется классически — предсказуемость и переносимость, ради которых MDD создавался, не появляются.

Как это работает #

MDD оперирует многоуровневой системой моделей и цепочкой трансформаций между ними. Ниже — механика в канонической формулировке OMG MDA, на которую опирается большинство MDD-внедрений.

Уровни абстракции: CIM → PIM → PSM → code #

Система описывается на четырёх уровнях, каждый из которых ближе к исполнению, чем предыдущий:

Уровень	Что описывает	Пример содержания	Кто работает
CIM (Computation Independent)	Бизнес-контекст и цели, безотносительно к автоматизации	Бизнес-процессы, правила, KPI, стейкхолдеры	Бизнес-аналитик, эксперт домена
PIM (Platform Independent)	Логическую архитектуру системы, без привязки к технологии	Доменные сущности, сервисы, контракты, потоки данных, состояния	Архитектор, моделёр
PSM (Platform Specific)	Архитектуру, привязанную к конкретной технологии	Схема таблиц JPA, REST-контроллеры Spring, маппинги ORM	Архитектор, моделёр (частично — автоматически)
Code	Исходный код, конфигурацию, схемы БД, тесты	Классы Java, SQL-миграции, дескрипторы развёртывания	Генератор (автоматически), разработчик (доработка)

Переходы между уровнями — трансформации: CIM→PIM (обычно ручной или полуавтоматический, требует участия человека), PIM→PSM (автоматический по правилам трансформации, привязанным к целевой платформе), PSM→code (автоматический кодогенерацией). Обратный путь (round-trip) теоретически возможен на каждом шаге, но надёжно работает только PSM→PIM.

Роли в MDD-процессе #

Роль	Зона ответственности	Аналог в классической разработке
Бизнес-аналитик / эксперт домена	CIM: бизнес-процессы, правила, стейкхолдеры	Business Analyst / SME
Архитектор-моделёр	PIM и PSM: логическая и платформо-зависимая архитектура; разработка и поддержка DSL	Solution Architect + Systems Engineer
Инженер трансформаций	Правила перехода PIM→PSM, шаблоны кодогенерации; настройка инструментального стека	Редкая роль; близка к tooling-инженеру / platform engineer
Разработчик	Доработка сгенерированного кода, ручные части, не охваченные моделью; фикс model-code gap	Developer

Ключевая особенность: в зрелом MDD доля «чистой» ручной разработки уменьшается, а вес архитектора-моделёра и инженера трансформаций — растёт. Это серьёзный кадровый сдвиг: роль разработчика размывается, а новых ролей на рынке немного.

Цикл работы #

MDD-цикл структурно отличен от минутного Red-Green-Refactor из TDD:

1. Спроектируй модель (PIM). Команда и архитектор формализуют логику системы на платформо-независимом уровне.
2. Трансформируй в PSM. Движок трансформаций применяет правила целевой платформы; PSM генерируется из PIM.
3. Сгенерируй код. Генератор кода превращает PSM в исходники, конфигурацию, схемы БД.
4. Проверь модель (simulation/testing). Поведение модели верифицируется — симуляцией, модельными тестами или тестами на сгенерированном коде.
5. Синхронизируй (round-trip). Если код правился вручную — изменения вносятся обратно в модель; если модель менялась — код регенерируется.

Шаги 1–5 повторяются на каждое значимое изменение. Цикл длится не минуты (как в TDD), а часы или дни — моделирование более «тяжёлая» операция, чем написание теста.

Связь с архитектурными уровнями #

MDD хорошо ложится на классическое разделение HLD и LLD: PIM по сути — формализованное HLD (логическая архитектура), PSM — формализованное LLD (привязка к технологии). Паттерны проектирования и System Design при этом описываются не только текстом, но и элементами модели — что делает архитектуру проверяемым, версионируемым артефактом. Каждое архитектурное решение, принятое при моделировании, целесообразно фиксировать и как ADR — особенно если оно определяет выбор целевых платформ или правил трансформации.

Влияние на команду и процесс #

MDD часто сводят к «инструменту для генерации бойлерплейта». Это сужение: устойчивый эффект возникает, только когда модельно-ориентированный процесс встроен в ролевую структуру команды и в управление жизненным циклом. Ниже — что именно меняется. Этот блок адресован прежде всего руководителям.

Новые роли и другая кадровая структура. MDD вводит роли, которых нет в классической agile-команде: архитектор-моделёр (владеет языком моделирования, DSL и правилами трансформации) и инженер трансформаций (настраивает движок PIM→PSM и шаблоны кодогенерации). Эти роли узки на рынке: найти людей с экспертизой одновременно в предметной области, в UML/DSL и в кодогенерации сложно. Проблема, которую это порождает: команда формально «внедрила MDD», но без сильного моделёра модели вырождаются в косметику, а без инженера трансформаций генератор выдаёт «приблизительный» код, который потом переписывается вручную — то есть теряется весь смысл подхода.

Сдвиг усилий вверх по жизненному циклу. В MDD львиная доля инженерного времени уходит на моделирование (PIM, PSM) и настройку трансформаций, а не на написание кода. Это прямая инверсия классического распределения: там, где обычно 70 % времени — код и 30 % — дизайн, в зрелом MDD пропорция может быть обратной. Проблема: руководитель, измеряющий прогресс «строками кода» или «закрытыми тикетами», видит MDD-команду как медленную на старте. Это управленческая ошибка: инвестиция в модель окупается на горизонте регенераций и переносов — когда тот же PIM порождает второй и третий PSM.

Качество моделей = качество продукта. В MDD дефекты модели автоматически становятся дефектами всего сгенерированного кода — то есть дефектами продукта. Это концентрирует риск: одна ошибка в PIM тиражируется во все PSM и во всю кодовую базу. Проблема: в классической разработке ошибка в одном модуле локализована; в MDD ошибка в модели системна. Отсюда жёсткое требование к качеству моделирования — ревью моделей, верификация (OCL-ограничения, симуляция), версионирование моделей наравне с кодом. Модель становится объектом code review в буквальном смысле.

Кривая обучения инструментам. MDD-стек (редактор моделей, репозиторий, движок трансформаций, генератор, синхронизатор) — узкоспециализированный и тяжёлый. Команда без опыта моделирования и без времени на обучение получает формальные модели, которые никто не поддерживает, и генератор, который никто не настраивает. Проблема: внедрение MDD «с понедельника» в команде, привыкшей писать код напрямую, почти всегда даёт фасад — MDD-theatre. Сначала пилот, обучение, выбор стека; потом — масштабирование.

Модели как аудируемый артефакт. В регуляторных доменах (банкинг, страхование, медицина, оборонка) модель в MDD — аудируемый артефакт: её можно предъявить регулятору как формальное описание системы, верифицировать на соответствие стандартам (например, DO-178C для авиации, IEC 62304 для медицинских устройств), использовать как доказательство соответствия требованиям. Это редкое и ценное свойство: в классической разработке «архитектурная документация» обычно расплывчата и не проверяема, а формальная модель — проверяема. Для команд, работающих в таких доменах, именно это свойство часто становится решающим аргументом за MDD.

Связь с комплаенсом и трассируемостью. Формальная модель даёт трассируемость (traceability): каждое требование в CIM прослеживается до элемента PIM, до элемента PSM и до сгенерированного кода. Это позволяет продемонстрировать регулятору или аудитору, где именно реализовано каждое требование — что в классической разработке требует отдельных инструментов (traceability matrix) и обычно быстро устаревает. В MDD трассируемость — побочный продукт процесса, а не отдельная работа.

Связь с жизненным циклом. MDD естественно ложится на ранние фазы SDLC: CIM покрывает фазу анализа требований, PIM — фазу архитектурного проектирования, PSM и код — фазы реализации. В отличие от гибких практик типа TDD, которые работают на фазе кодирования, MDD перестраивает именно верхние фазы цикла, делая их формальными и верифицируемыми.

Преимущества #

Переносимость между платформами. Разделение PIM/PSM позволяет из одной платформо-независимой модели получать несколько платформо-зависимых реализаций — например, PIM сервисной модели порождает PSM для Spring + JPA и PSM для .NET + EF. Переносимость здесь — не обещание «перепишем за неделю», а механическое свойство модели: PIM зафиксирован, меняется только правило трансформации.

Согласованность кода и модели. Когда код выводится из модели, расхождение между ними — дефект процесса, а не норма. Это решает классическую проблему «документация устарела в день релиза»: модель остаётся актуальным описанием системы, потому что код из неё регенерируется.

Быстрый прототип на новую платформу. При наличии готового правила трансформации переход PIM→PSM для новой платформы — это не многомесячный проект, а настройка трансформации. Это особенно ценно для семейств продуктов (product lines), где один и тот же функционал должен работать на нескольких технологических стеках.

Снижение ручного бойлерплейта. Механическая часть кода (маппинги ORM, DTO-конверсии, REST-контроллеры по контракту, SQL DDL из схемы) генерируется автоматически. Это убирает значительный объём рутины и — что важнее — убирает связанный с рутиной класс ошибок (опечатки в маппингах, рассинхронизация схемы и кода).

Трассируемость и комплаенс. Каждое требование прослеживается от CIM через PIM и PSM до кода. В регуляторных доменах это решает задачу, которую в классической разработке приходится решать отдельными инструментами и которая в них же обычно ломается.

Верификация на уровне модели. Исполняемые модели и constraint-языки (OCL) позволяют обнаруживать дефекты логики до генерации кода — на самом дешёвом уровне исправления. Это структурный аналог принципа shift-left, но применённый не к тестам (как в BDD), а к моделям.

Недостатки и риски #

Сложность и незрелость инструментов. MDD-инструментальный стек тяжел, дорог и фрагментирован: нет «стандартного» открытого набора, сопоставимого по зрелости с экосистемами вокруг Spring или .NET. Коммерческие инструменты (Enterprise Architect, Rational Rhapsody, MagicDraw) мощны, но дороги и陡; открытые (Eclipse Modeling Framework, Papyrus) требуют значительной настройки. Проблема: слабый инструмент сводит MDD к фасаду, а сильный — требует выделенной роли инженера инструментов.

Утечка абстракций (abstraction leakage). Идея «опиши модель — получи готовый код» на практике сталкивается с тем, что часть поведения плохо выражается на уровне модели (специфичные оптимизации, хитрые интеграционные сценарии, нюансы конкретного API). В таких местах сгенерированный код приходится править вручную — и модель перестаёт быть точным описанием системы. Чем больше таких мест, тем сильнее MDD вырождается в «обычную разработку с дополнительной моделью для отчётности».

Round-trip engineering практически проблемен. Двунаправленная синхронизация «код → модель» — самое слабое место MDD. Большинство реальных MDD-внедрений работают в режиме one-way generation (модель → код) с пометкой сгенерированных регионов как «не редактировать»; round-trip либо не используется, либо работает ненадёжно. Проблема: без round-trip любое ручное изменение кода неминуемо ведёт к расхождению с моделью, а полностью избежать ручных правок почти никогда не удаётся.

Model-code gap. Расхождение между моделью и кодом — главный источник хрупкости MDD-проектов. Симптом: формально модель есть, но «правильная» — в коде, а модель устарела. Это превращает модель из актива в обузу: на её поддержку тратится время, а доверия ей нет. Решается только дисциплиной (модель как primary source) и инструментами (запрет прямых правок в сгенерированном коде).

Нишевые навыки и узкий рынок кадров. Архитекторы-моделёры и инженеры трансформаций — редкие специальности; найм и обучение стоят дорого. В регионах и командах без MDD-культуры это может сделать подход практически нереализуемым. Это также повышает bus-factor: уход единственного моделёра обнуляет инвестиции в модель.

Ограниченная применимость к современным стекам. MDD формировался в эпоху J2EE и тяжёлых enterprise-платформ; для современных динамических стеков (serverless, edge, ML-пайплайны, event-driven) модельно-ориентированный подход разработан слабо. Готовых трансформаций под новые технологии мало, и их приходится строить силами команды — что съедает часть выгод.

Риск «MDD-theatre». Как и с любой методологией, формальное внедрение без сути даёт фасад: модели рисуются «для отчётности», код пишется классически, а генератор используется точечно. Результат — двойная работа (модель + код) без выгод переносимости и согласованности. Симптом: модель обновляется постфактум, после того как код уже написан вручную.

Когда использовать #

• Регуляторные домены. Банкинг, страхование, медицина, оборонка — там, где требуется формальная верифицируемая архитектура, трассируемость требований и аудируемость модели (DO-178C, IEC 62304, Basel III). Здесь MDD часто не выбор, а требование стандарта.
• Семейства продуктов (product lines). Когда один и тот же функционал должен работать на нескольких платформах или в нескольких конфигурациях — PIM становится переиспользуемым ядром, а PSM-ы — вариациями. Это классическая зона применения MDD (Software Product Line Engineering).
• Стабильные, повторяющиеся архитектуры. Если команда раз за разом строит системы по одному и тому же архитектурному шаблону (микросервис с CRUD, корпоративный портал, биллинговый движок), инвестиция в модель и трансформации окупается на третьем-четвёртом проекте.
• Генерация под несколько платформ. Один PIM → Java + .NET + Node.js → три кодовые базы из одной модели. Выгоды масштабируются с числом целевых платформ.
• Долгоживущие системы. Инвестиция в модель окупается на горизонте лет: модель переживает смены технологий, оставаясь ядром системы. Для коротких проектов накладные расходы не оправданы.
• Есть сильный архитектор-моделёр. Это предусловие, а не пожелание: без него модели превращаются в косметику, а трансформации — в генерацию бойлерплейта низкого качества.

Когда НЕ использовать #

• Стартапы и исследовательская разработка. Когда предметная область и сама архитектура быстро меняются, формальная модель устаревает быстрее, чем окупается; гибкость важнее переносимости. Здесь работают Agile в лёгкой форме или Lean Startup.
• Продукты с быстро меняющимися требованиями. Если функционал переворачивается раз в месяц, модель не успевает за реальностью; трансформации постоянно перенастраиваются, а выгоды переносимости не успевают материализоваться.
• Малые команды без экспертизы моделирования. Команды из 3–5 человек без архитектора-моделёра получают от MDD больше накладных расходов, чем выгоды. Им ближе XP или Scrum.
• Инновационные технологические стеки. Serverless, edge, ML-пайплайны, event-driven — домены, где MDD-инструментарий слаб и где формальное моделирование часто запаздывает за технологией. Здесь модель — лишний слой абстракции без поддержки.
• Команда без сильного моделёра. Нет человека с экспертизой в UML/DSL, метамоделях и трансформациях — нет и MDD; процесс превратится в MDD-theatre.

Связанные подходы #

MDD — не единственный «*DD» в разработке; за разными аббревиатурами стоят разные «движущие силы». Статья входит в серию материалов о driven-подходах; ниже — краткая карта, со ссылками на уже опубликованные материалы базы знаний.

Подход	Движущая сила	Что управляет дизайном	Уровень применения
TDD	Тесты	Тесты как исполняемая спецификация (Red-Green-Refactor)	Код и команда
DDD	Домен	Модель предметной области и единый язык	Команда и организация
BDD	Поведение	Сценарии Given-When-Then на уровне требований	Команда и заказчик
FDD	Функция (фича)	Процесс доставки фичи: модель → список фич → реализация	Команда и организация
MDD (этот материал)	Модель	Формальная модель как источник истины; код — производное	Организация и архитектура

MDD и близкие понятия: явные разведения #

Три понятия, которые регулярно смешивают с MDD, важно развести явно.

Model-First — это не MDD. Model-First означает лишь разовое проектирование модели перед кодом («нарисуем диаграмму классов, потом кодим»). Это действие, а не методология: после первого релиза модель и код расходятся, и подход заканчивается. MDD требует, чтобы модель оставалась primary source of truth на всём жизненном цикле — это системное свойство процесса, а не разовый шаг.

Low-Code / No-Code — продуктовая категория, а не методология. Low-code-платформы (OutSystems, Mendix, Appian) реализуют идею MDD коммерчески: пользователь строит модель в визуальном редакторе, а платформа генерирует код и обеспечивает исполнение. Концептуально это MDD, но с ключевым отличием — модель, правила трансформации и целевая платформа принадлежат вендору, а не команде. Команда не контролирует кодогенерацию и не может настроить трансформации под свой стек; она работает в рамках, заданных платформой. Это меняет экономику: вместо инвестиции в собственный MDD-стек команда покупает готовый — ценой привязки к вендору.

MDD vs AIDD — «новый MDD». Появление AI-генерации кода из текстовых спецификаций (AIDD) иногда описывают как «новый MDD»: и там, и тут код выводится из описания более высокого уровня. Однако разница фундаментальна. В MDD источник истины — формальная модель (UML/DSL с метамоделью, OCL-ограничениями, верифицируемой семантикой); трансформации к коду — детерминированные и воспроизводимые. В AIDD источник истины — текстовая спецификация на естественном или полуструктурированном языке (Markdown, Gherkin, tasklist); «трансформация» в код — вероятностная генерация LLM, требующая валидации тестами и ревью. Формальная модель MDD аудируема и проверяема до кода; текстовая спецификация AIDD — нет. AIDD выигрывает в гибкости и скорости (спеку проще написать, чем формальную модель), но проигрывает в верифицируемости и переносимости (из текстовой спеки нельзя механически вывести вторую платформу). На практике подходы скорее дополняют друг друга: формальная модель может служить контекстом для AI-генерации, а AI — помогать в построении самой модели.

Родственные материалы серии и базы знаний #

• TDD — Test Driven Development — родственный подход, где движущей силой выступают тесты как исполняемая спецификация. MDD и TDD не конкурируют: MDD задаёт формальную модель как источник истины, TDD страхует поведение сгенерированного кода тестами. Часто они сочетаются — тесты пишутся против модели, а код генерируется.
• DDD — Domain Driven Design — родственный модельно-ориентированный подход. Общее: опора на модель как первичный артефакт. Различие: DDD говорит о модели предметной области (домен как язык и источник паттернов), MDD — о формальной модели системы (UML/DSL как источник кода). DDD-модель может быть входом для MDD-трансформаций.
• BDD — Behaviour Driven Development — родственный подход, где движущей силой выступает поведение в сценариях Given-When-Then. BDD и MDD сдвигают фокус вверх по жизненному циклу, но на разные артефакты: BDD — на требования, MDD — на архитектуру.
• FDD — Feature Driven Development — организационная методология, где движущей силой выступает клиенто-ориентированная фича. FDD строит модель предметной области до кода (как MDD), но использует её операционно — для декомпозиции на фичи, — а не как источник для автоматической генерации кода.
• AIDD — AI-Driven Development: разведение MDD vs AIDD см. выше.
• HLD и LLD — PIM по сути формализует HLD, PSM — LLD; MDD делает эти уровни явными, версионируемыми и проверяемыми артефактами.
• Паттерны проектирования — элементы модели (классы, интерфейсы, компоненты) опираются на классические паттерны; формальная модель делает их применение явным.
• System Design — системный дизайн как содержательная основа PIM; MDD формализует его на языке моделирования.
• ADR — фиксация архитектурных решений, в том числе о выборе языков моделирования, целевых платформ и правил трансформации.
• SDLC — где MDD живёт внутри жизненного цикла: CIM покрывает фазу анализа, PIM — фазу проектирования, PSM и код — фазы реализации.

Родственные driven-подходы — TDD, BDD, DDD, FDD, ATDD (критерии приёмки), а также «сатирические» варианты вроде Panic Driven Development — рассматриваются в соответствующих статьях серии.

Краткий вердикт для руководителя #

MDD — это методология для зрелых, формальных и часто регулируемых контекстов, а не способ сделать команду быстрее здесь и сейчас. Эффект: переносимость между платформами (один PIM → несколько PSM), согласованность кода и модели как системное свойство, снижение ручного бойлерплейта, трассируемость и комплаенс в регуляторных доменах. Цена: тяжёлый и фрагментированный инструментальный стек, узкий рынок кадров (архитекторы-моделёры, инженеры трансформаций), утечка абстракций в местах, плохо описываемых моделью, и хроническая проблема model-code gap. Берите, если домен регулируемый, архитектура стабильна и повторяема, нужна генерация под несколько платформ, а в команде есть сильный моделёр и бюджет на инструменты. Не берите, если продукт — стартап, требования летают, стек инновационный (serverless, ML), или нет людей с экспертизой моделирования. Оценивать MDD на горизонте одного спринта — ошибка; эффект проявляется на горизонте регенераций и переносов, когда инвестиция в PIM окупается через переиспользование. И помните: «AI-генерация из спецификаций» (AIDD) — это не «новый MDD», а другой класс подхода: вероятностный вместо детерминированного, текстовая спека вместо формальной модели.

Источники и материалы #

Первоисточники и ключевые публикации #

• OMG. Model Driven Architecture (MDA) — OMG Document number ormsc/2001-07-01, 2001 — фундаментальный первоисточник стандарта MDA, формулировка уровней CIM/PIM/PSM и принципов модельно-ориентированной разработки.
• OMG. Meta Object Facility (MOF) Core Specification — метамодельный фундамент MDA, на котором строятся языки моделирования и трансформации.
• Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering in Practice. Morgan & Claypool / Springer, 2017 (2-е изд.) — канонический современный обзор MDE/MDD: принципы, инструменты, индустриальные кейсы, эмпирические данные о применимости.
• Douglas C. Schmidt. Model-Driven Engineering. IEEE Computer, 2006 — классический обзорный материал о месте MDE в программной инженерии.
• Thomas Stahl, Markus Völter. Model-Driven Software Development: Technology, Engineering, Management. Wiley, 2006 — операционное руководство по внедрению MDD в проектах: от выбора DSL до построения трансформаций.
• Steven Kelly, Juha-Pekka Tolvanen. Domain-Specific Modeling: Enabling Full Code Generation. Wiley-IEEE, 2008 — глубокий разбор DSL-подхода к MDD и полной кодогенерации.
• Michał Śmialek et al. материалы и доклады по MDE в индустриальных проектах — практика применения и адаптации подхода.

Связанные материалы базы знаний #

• TDD — Test Driven Development — родственный driven-подход; тесты как движущая сила против модели как движущей силы. MDD и TDD сочетаются: тесты страхуют сгенерированный код.
• DDD — Domain Driven Design — родственный модельно-ориентированный подход; DDD-модель домена может служить входом для MDD-трансформаций.
• BDD — Behaviour Driven Development — сдвиг фокуса вверх по жизненному циклу, но на уровень требований, а не архитектуры.
• FDD — Feature Driven Development — модель предметной области как стартовый артефакт, но для декомпозиции на фичи, а не для генерации кода.
• AIDD — AI-Driven Development: разведение MDD vs AIDD (формальная модель vs текстовая спецификация, детерминированная трансформация vs вероятностная генерация).
• HLD и LLD — уровни, формализуемые в MDD как PIM и PSM соответственно.
• ADR — фиксация архитектурных решений о выборе языков моделирования и правил трансформации.
• System Design и Паттерны проектирования — содержательная основа PIM.
• SDLC — место MDD в жизненном цикле разработки.