Есть ли опыт работы с Domain-Driven Design (DDD)?

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

Отличаете ли вы DDD от набора папок Domain, Application, Infrastructure. Интервьюеру важно услышать, как вы делили предметную область и где проводили границы. Следом обычно спрашивают, как вы выделяли агрегаты и когда DDD был бы лишним.

Как отвечать

Стройте ответ вокруг своего проекта: какой был домен, почему обычного CRUD не хватило, что вы сделали. Нужны свои примеры и, если есть, свои цифры. Опорные понятия, которые стоит показать на этом примере:

• ограниченный контекст и единый язык: «заказ» в продажах и «заказ» на складе это разные модели, у каждого контекста свой код и свои термины, согласованные с бизнесом;
• агрегат: граница согласованности, изменения идут через корень и сохраняются одной транзакцией, а между агрегатами ссылаются по идентификатору;
• объект-значение: Money, Email, Period без идентичности, неизменяемые, с проверкой в конструкторе. В PHP 8.2 их удобно делать readonly-классами;
• доменные события и репозитории: событие фиксирует факт вроде OrderPaid, репозиторий прячет хранилище за интерфейсом из домена.

Покажите и стек. В Symfony с Doctrine объекты-значения мапятся через Embeddable, а маппинг выносят в XML, чтобы доменные классы не зависели от ORM. События удобно гонять через Symfony Messenger, а границы слоёв проверять Deptrac в CI. Про Laravel честно скажите о трении: Eloquent это Active Record, и чистую доменную модель рядом с ним держать сложнее.

Если настоящего DDD-проекта не было, так и скажите: какие практики применяли точечно (объекты-значения, слой сервисов, события) и почему в том проекте полный DDD был бы избыточен. Это сильнее придуманной истории.

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

Описывают только тактические шаблоны и не могут объяснить, как выбирали границы контекстов. Без стратегической части это просто слоистая архитектура.

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

Рассказывают про «сократили время разработки на 30%» и не могут ответить, как это считали.