В данной статье, я расскажу о том, как возможно DDD сейчас обретает своё третье перерождение. Первое в 2003 году, по выходу книги, второе с выходом микросервисов и пониманием гранулярности, и последний - с развитием ИИ.
В этой статье я расскажу о том, как не заниматься боллерплейтом вообще, сконцентрировавшись больше на дискаверинге, как получить дюжину готовых микросервисов за считанные часы. Вас ждёт генезис, фактура и исходники, рассказ как это можно применять. И возможно, DDD больше не будет элитарным, а кризис мы сможем считать преодолённым.
Впервые с DDD я познакомился на AgileDays 2019, где была техническая сессия, из которой появилась конференция ArchDays. Это был один из моментов в жизни, который называли раньше “Эврика” - всё стало предельно ясно, всё сложилось воедино.
Дороговизна как структурная проблема
В 2019 году я писал: DDD дорог. Максим Аршинов говорил об этом открыто. Эванс не скрывал: команда должна быть высокой квалификации, а значит — дорогой.
Тогда я видел в этом проблему. Сейчас как никогда я вижу и понимаю, что это было диагнозом, а не приговором. Дороговизна DDD — не случайность и не злой умысел коучей. Это объективное следствие того, что DDD оставался ремеслом.
Ремесло — это когда результат зависит от мастерства конкретного человека. Ремесло не масштабируется. Ремесло не индустриализируется. Ремесло — это когда один архитектор может построить собор, а тысяча архитекторов построят тысячу соборов, каждый из которых будет уникален, но ни один не будет похож на тот, что нужен заказчику.
Книга Фабрики разработки программ. Потоковая сборка приложений
В 2004 году вышла уникальная книга от архитекторов Microsoft (Джек Гринфилд, Кит Шорт, Стив Кук, Стюарт Кент) о модель-ориентированной разработке (MDD), предметно-ориентированных языках (DSL), повторном использовании кода, паттернах и продукт-линии. Авторами рассматривается проблемы необходимости повторного написания кода с нуля программистами, даже если проекты схожи, что медленно, дорого и чревато ошибками. В книге предлагается создать производственную линию, где:
Есть стандартные чертежи (модели и паттерны).
Используются станки и конвейеры (инструменты автоматизации).
Работают специалисты разных профилей, собранные в эффективный процесс.
Вот две ключевые цитаты, которые наиболее точно передают эту идею на русском языке.
Первая цитата: Сравнение с промышленной революцией
Эта цитата из введения к книге «Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools» показывает, что индустриализация — это естественный этап эволюции, который позволяет преодолеть ограничения «ручного труда».
Цитата:
«За последние десять лет индустрия программного обеспечения удовлетворяла потребности все более автоматизируемого общества, оттачивая навыки отдельных разработчиков, подобно тому, как ремесленники удовлетворяли потребности индустриального общества на ранних стадиях промышленной революции, оттачивая мастерство отдельных craftsmen’ов. До определенного момента это эффективный способ удовлетворения спроса. Однако за этой точкой производственные возможности быстро исчерпываются, поскольку мощность отрасли, основанной на ремесленном труде, ограничена ее методами, инструментами и размером пула квалифицированной рабочей силы. Беглый взгляд на состояние программных проектов показывает, что мы уже изо всех сил пытаемся удовлетворить спрос, используя текущие средства производства» .
Вторая цитата: Масштаб проблемы (Статистика)
В той же работе, а также в статье «The Case for Software Factories» (2004), Гринфилд использует конкретные данные, чтобы показать неэффективность текущего «кустарного» подхода и неизбежность перемен.
Цитата:
«Разработка программного обеспечения в том виде, в котором она практикуется сегодня, медленна, дорогостояща и подвержена ошибкам. … Только 16% проектов завершаются в срок и в рамках бюджета. Еще 31% отменяются, в основном из-за проблем с качеством. Еще 53% превышают свои бюджеты в среднем на 189%. … Эти цифры объективно подтверждают то, что мы уже знаем по опыту: разработка ПО требует больших затрат труда, потребляя больше человеческого капитала на доллар произведенной стоимости, чем мы ожидаем от современной индустрии. … Эту ситуация должна измениться. Совокупный мировой спрос на программное обеспечение, по прогнозам, вырастет на порядок в течение следующего десятилетия. … Поскольку мощность отрасли зависит от размера пула компетентных разработчиков и производительности ее членов, увеличение мощности требует либо больше разработчиков, использующих текущие методы, либо сопоставимого числа разработчиков, использующих другие методы. Решение должно включать изменение наших методов и практик. Мы должны найти способы сделать разработчиков гораздо более продуктивными».
Мы не можем строить цифровую экономику на ремесле. Нам нужна технология.
Парадокс: DDD создан для борьбы со сложностью. Но он сам эту сложность воспроизводит — на других уровнях. Самое страшное, что стремительный прогресс, связанный с развитием ИИ, может оставить эту методологию за бортом.
Поиск ответа
В 2020 году я написал, что DDD как конструктивизм - левая архитектура. Требует горизонтальной организации, отрицает иерархию, срастается с настоящим Agile. За за этой декларацией стоял практический вопрос: как организовать труд, чтобы DDD перестал быть элитарным?
Горизонтальная организация, продуктовые команды, общая цель — это условия, без которых DDD не взлетает. Но даже с ними остаётся проблема ремесла. Мы можем поставить самую горизонтальную команду в мире, но если каждый разработчик будет вручную писать инфраструктуру для каждого агрегата — мы утонем.
Важная часть этого этапа для меня - SeedWorks Hive. Уже на первых шагах применения предметно-ориентированного проектирования, на который было решено пойти - сделать Open Source библиотеку Seedworks, т.е. которая закрепляет тактические паттерны, монады, интерфейсы. Тогда доменов было так много, что схемы напоминали улей - так проект и назвали.
В прошлой статье я описывал первое место работы над ЭДО, где мы с коллегами пришли к пониманию формы. Двигаясь циклически, ретроспективно улучшая процесс, наша библиотека росла, а после первых микросервисов появилось другое понимание - нужно абстрагировать так много логики, как только возможно. К сожалению, на тот момент эти идеи были концептами. В следующей вехе - EDM, стало ясно что платформизация и интеграция с инфраструктурой - важные направления, которые нужно активно развивать.
DigiTFactory
Hive стал прообразом DigiTFactory. Мы поняли, что тактические паттерны можно стандартизировать — и пошли дальше, к автоматизации целых микросервисов».
Digital twin factory - мой проект по индустриализации DDD - фабрика событийно-управляемых микросервисов.
В первую итерацию проект представлялся следующим образом:
Архитектура фабрики - план по которому нужно было двигаться для построения фабрики.
SeedWorks для общей рамки тактических паттернов.
Референсный пример микросервиса Чат
К сожалению, проект буксовал 2,5 года, но прогресс всё поменял.
DigiTFactory: от ремесла к индустрии
DigiTFactory.Libraries
Это не библиотека. Это фабрика микросервисов.
SeedWorks — тактические паттерны, монады, интерфейсы. Домен не знает об инфраструктуре.
CommandRepository - Event Store на PostgreSQL и MongoDB.
ReadRepository - материализованные представления.
EventBus - Реализация шины доменных событий.
Всё собирается как Lego. Хотите Kafka вместо InMemory? Заменили пакет. Хотите Scylla вместо Postgres? Заменили пакет. Код домена не меняется.
Ключевые принципы:
Домен в центре. Domain зависит только от SeedWorks — никакой инфраструктуры.
Иммутабельность. Никаких setter’ов. Изменения только через бизнес-операции.
Событие как источник истины. Шина событий — центральный порт. БД — адаптер.
Трёхуровневая валидация. Assertions → Validators → Success/Exception/Warnings.
Plug & Play инфраструктура. Сменить Postgres на Mongo или Redis на Scylla — замена одного пакета.
Но главное — генерация.
Claude и архитектор меняют правила
Мы обучили Claude Code работать с нашими артефактами. Теперь вы:
Рисуете Context Map (в Miro, PlantUML, любом тексте).
Описываете Bounded Context Canvas (сущности, команды, события, инварианты).
Указываете API (OpenAPI, gRPC, или просто список методов).
Claude генерирует:
Полноценный микросервис на .NET с гексагональной архитектурой.
Все агрегаты, Value Objects, бизнес-методы.
Репозитории, материализованные представления.
Шину событий, обработчики команд и запросов.
Интеграционные тесты.
Десятки человеко-дней в часы.
Пример: интернет-магазин за один вечер
Возьмём типовой интернет-магазин:
Корзина, заказы, оплата, доставка.
Инварианты: «нельзя оплатить заказ, если корзина пуста», «товар должен быть на складе».
Мы описали 7 субдоменов, 16 агрегатов, 30+ бизнес-методов. Claude сгенерировал 4 микросервиса (CEQRS, Kafka, Scylla) за сутки диалога. Раньше это заняло бы месяцы работы (если не сказать что по факту выходили годы для отдельных команд). И это только первая версия. Поддержка, эволюция модели, добавление новых фич — тоже автоматизированы.
В репозитории документация, код, конфигурация развёртывания.
Пример: банковская система без ночных кошмаров
Банк — это страшилка DDD. Платежи, счета, лимиты, транзакции. Инварианты: «баланс не может быть отрицательным», «суточный лимит не должен превышать…», «транзакция не может быть отменена после исполнения».
На основе регуляторных требований было сформулировано 14 ограниченных контекстов. Первые три микросервиса в диалоге делались 3 часа, а остальные параллельно ещё за 40 минут.
В репозитории регуляторные требования, описание доменов, код, конфигурации развёртывания.
Что это меняет для DDD
Перестаёт быть дорогим.
Не потому, что мы снизили квалификацию команды. А потому, что мы автоматизировали рутину. Время, которое раньше уходило на написание репозиториев и настройку шины, теперь уходит на моделирование предметной области. А это — единственное, ради чего DDD затевался.
Перестаёт быть элитарным.
Раньше DDD могли позволить себе компании с толстыми кошельками и командами из Senior-разработчиков. Теперь — любая продуктовая команда, у которой есть реплицируемый продукт и горизонтальная культура. DigiTFactory не заменяет квалификацию, но снижает порог входа.
Перестаёт быть горизонтальным.
Перестаёт требовать горизонтальности как предварительного условия. DigiTFactory не делает команду горизонтальной, но он не мешает ей быть такой. Инструмент не заменяет культуру, но он даёт фору тем, кто её уже создал.
А что с кризисом DDD сообщества?
Кризис был не в DDD. Кризис был в способе его производства. Пока DDD оставался ремеслом, он был обречён на элитарность, дороговизну и бесконечные споры об анемичной модели, F#, Event Sourcing и прочем.
Сейчас эти споры теряют смысл. Потому что технические детали уходят в библиотеку. Остаётся модель. А модель — это то, ради чего мы здесь.
Что дальше?
Возвращаясь к метафоре конструктивизма: мы прошли путь от кубизма и авангарда (тактические паттерны) к конструкции (EDM) — и теперь готовы к промышленному использованию (фабрика).
Я закрываю тему DDD. Не потому, что мне нечего сказать. А потому, что сказанное можно теперь не повторять, а использовать.
DigiTFactory открыт. Код — на GitHub. Документация — в репозитории. Референсные микросервисы — там же. Skill для Claude Code — пожалуйста.
Коллеги, пользуйтесь:
Skill для Claude Code: Skill - загружаете артефакты, получаете микросервис
Артефакты: DDD Discovery Canvas — для подготовки канвасов
Я не жду, что завтра все бросятся переписывать свои монолиты на CEQRS. Но я знаю, что те, кто искал способ сделать DDD массовым, теперь его получили.
Остальное — дело сообщества. Форкайте, дорабатывайте, пишите статьи, делайте PR. Или нет. Инструмент работает и без вас.
Вместо послесловия
Когда-то я начал с «Кризиса DDD сообщества». Где жаловался, что подход искажают, упрощают, делают «быстрорастворимым». Конечно же, всем всегда не хватало подходящего инструмента - и весь вопрос был всегда в том как выстроить его.
Теперь он есть.
Берите. Генерируйте. Стройте сложные системы без боллерплейта.
И помните: DDD был, есть и будет про модель. Всё остальное — теперь просто автоматизация.
P.S. Если вы дочитали до этого места — вы из тех, кому небезразлично, как мы строим цифровой мир. Я писал эти статьи пять лет, строя этот инструмент в работе, спорах, корпоративно-политических перипетиях. Спасибо, что были с этим текстом. Теперь — дело за вами.
