Что такое DDD

Что проверяют

Отличаете ли вы DDD от раскладывания проекта по папкам. Вопрос почти всегда про то, умеете ли вы держать бизнес-правила в одном месте и разговаривать с заказчиком его словами, а не про названия паттернов. В Node это заметно особенно: типовой сервис быстро расползается на контроллеры, где логика перемешана с запросами через ORM.

Как отвечать

DDD это подход, в котором первична модель предметной области и язык, общий у бизнеса и разработчиков, а технологии вторичны. Главное здесь единый язык и границы: ограниченный контекст задаёт область, внутри которой термин значит одно и то же, и у соседнего контекста своя модель того же слова, а не общая таблица на всех.

Тактические кирпичи: сущность (важна идентичность), объект-значение (важен состав, неизменяем), агрегат (граница согласованности, снаружи виден только корень), репозиторий (отдаёт и сохраняет агрегат целиком), доменное событие. Правило транзакции простое: одна транзакция меняет один агрегат, ссылки между агрегатами по идентификатору.

Для Node это означает, что доменный слой не знает про HTTP-фреймворк, ORM и очередь. Он на чистом TypeScript, а фреймворк живёт в слое приложения и инфраструктуры и вызывается снаружи внутрь.

Где спотыкаются

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

Тянут DDD в CRUD. Если система перекладывает формы в таблицы, слои и мапперы дают только лишний код. Подход окупается там, где правил много и они меняются.

Делают один контекст на всё приложение и общую модель. Тогда сущность обрастает полями всех сценариев сразу, и любая правка задевает половину системы. Отдельная модель на контекст с явным переводом на границе обходится дешевле.