В чем главное преимущество DDD по сравнению с альтернативами
Что проверяют
Можете ли вы назвать главное преимущество, а не перечислить все паттерны из книги Эванса. Интервьюер хочет услышать, что DDD решает проблему сложной предметной области, и почти всегда спрашивает следом, когда DDD брать не стоит.
Как отвечать
Главное преимущество: код повторяет модель бизнеса. Термины, границы и правила предметной области живут в коде в тех же словах, в которых о них говорят эксперты, поэтому новое требование находит своё место без перевода и раскопок по сервисам.
Держится это на двух уровнях:
- стратегический: единый язык (ubiquitous language) и ограниченные контексты (bounded context). «Заказ» в продажах и «заказ» на складе это разные модели с разными правилами, DDD разрешает им быть разными, а связи между контекстами описывает явно, при необходимости через антикоррупционный слой;
- тактический: агрегаты, которые охраняют инварианты, объекты-значения, доменные события, репозитории на уровне агрегата.
Сравните с альтернативами. Transaction script и анемичная модель с сервисами проще на старте, но правила расползаются, и одно условие проверяется в пяти местах. CRUD вокруг таблиц хорош, пока логики почти нет.
Для C# добавьте конкретику: сущность с приватными сеттерами и методами вроде order.AddItem(...), коллекция наружу как IReadOnlyCollection<T>, объекты-значения на record, в EF Core их маппинг через OwnsOne или complex types. Доменные события копят в агрегате и публикуют при SaveChangesAsync.
Цену тоже назовите: нужен доступ к экспертам, больше кода и время на моделирование. На админке или справочнике это не окупается.
Где спотыкаются
Отвечают набором паттернов: «репозитории, сущности, value objects». Без единого языка и контекстов от DDD остаются только названия папок.
Приравнивают DDD к микросервисам. Ограниченный контекст помогает провести границы сервисов, но DDD отлично живёт и в модульном монолите.
Строят анемичную модель с DDD-названиями: сущности с публичными сеттерами, а вся логика в OrderService. Инварианты никто не охраняет, и агрегат легко собрать в невалидном состоянии.