Зачем нужен подход объектно-ориентированного проектирования на основе сущностей бизнес-домена

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

Понимаете ли вы, зачем код должен говорить на языке бизнеса и где при этом живут правила. По сути это вопрос про Domain-Driven Design и богатую доменную модель против анемичной. Следом обычно спрашивают, как это сочетается с JPA-сущностями и когда такой подход избыточен.

Как отвечать

Классы повторяют понятия предметной области: Order, Customer, Money, а бизнес-правила живут внутри этих классов, а не размазаны по сервисам. Тогда разработчик и аналитик называют вещи одинаково, и изменение правила находится в одном месте.

• единый язык: термины в коде совпадают с терминами бизнеса. Если отдел продаж говорит «отменить заказ», в коде есть order.cancel(), а не orderService.updateStatus(id, 5);
• инварианты внутри объекта: Order сам не даст добавить позицию после оплаты и сам пересчитает сумму. Публичные сеттеры на всех полях эти инварианты ломают;
• value objects: Money, Email, Period без идентичности, неизменяемые, со сравнением по значению. В Java их удобно делать через record с проверкой в компактном конструкторе;
• агрегаты: группа объектов с одним корнем, изменения идут только через корень, репозиторий заводится на агрегат, а не на каждую таблицу;
• ограниченные контексты: «клиент» в продажах и в поддержке может быть разными моделями.

В Spring-проекте доменный слой держат без зависимостей от фреймворка. Прикладной сервис с @Transactional загружает агрегат, вызывает у него метод и сохраняет. Для CRUD-админки вся эта конструкция лишняя, окупается она там, где много бизнес-правил.

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

Отвечают про три кита ООП и наследование товаров. Иерархия Product и ElectronicProduct почти всегда хуже композиции, и к сути вопроса она отношения не имеет.

Выдают анемичную модель за доменную: сущность с геттерами и сеттерами, а вся логика в OrderService. Мартин Фаулер описал это как антипаттерн.

Не видят конфликта с JPA: конструктор без аргументов и ленивые связи тянут инфраструктуру в домен. Нужно уметь сказать, идёте ли вы на этот компромисс или маппите JPA-сущности в доменные отдельно.