Насколько жестко проект был разделен на ограниченные контексты и агрегаты в DDD

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

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

Как отвечать

Опишите жёсткость по шкале, а не одним словом. Проговорите, на каком уровне стояли границы:

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

Про агрегат скажите главное: это граница транзакции и инвариантов. Одна транзакция меняет один агрегат, остальное догоняет событиями, поэтому в Node обычно заводят таблицу исходящих сообщений, из которой отправка идёт отдельно от бизнес-операции. Если домен лежал поверх сущностей ORM и вся логика жила в сервисах, честно назовите это анемичной моделью и скажите, чем она аукнулась.

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

Называют словом DDD набор папок domain, application, infrastructure. Интервьюер спросит, где проверяются инварианты, и выяснится, что в сервисном слое, а сущность это просто структура с полями и геттерами.

Второе: делают агрегат огромным. Пользователь со всеми заказами внутри означает длинные транзакции, блокировки на популярных записях и постоянные конфликты версий при оптимистичной блокировке. Мелкий агрегат плюс события почти всегда лучше.

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