Я знаком с типичной многоуровневой архитектурой, состоящей из сервисов, сущностей и репозиториев. Службы манипулируют аннотированными классами сущностей, которые сохраняются в репозиториях. В этой модели классы сущностей представляют собой просто анемичные контейнеры данных с кучей геттеров и сеттеров. Бизнес-логика находится в процедурных сервисных классах (синглтонах, управляемых контейнером Spring).
Я изучаю DDD в качестве хобби-проекта. В DDD сущности образуют богатую модель предметной области, которая вмещает большую часть бизнес-логики в совокупных корневых методах (и объектах значений). Сервисы — это почти просто координаторы сотрудничающих объектов, репозиториев и других сервисов. Богатая модель предметной области обеспечивает соблюдение бизнес-ограничений и инвариант истинного подхода ООП, а также способствует удобству сопровождения кода. Кроме того, модель предметной области является ядром шестиугольной архитектуры, то есть это просто POJO, не зависящие от технических или инфраструктурных проблем на уровне исходного кода.
Но спецификация JPA требует, чтобы объектный компонент имел общедоступные методы получения и установки, что по своей сути является анемичным контейнером данных, что является противоположностью модели домена DDD. Так следует ли мне объединить логику предметной области внутри объекта JPA? Или мне следует поддерживать две разные модели и логику сопоставления при работе с ORM на DDD? Где должна находиться эта модель и логика сопоставления на уровне проекта?
