Как избежать анемичного доменного слоя и все еще иметь богатую проверку и бизнес-правила

• , Если объект является объектом значения, это должно быть неизменно и проверено во время конструкции.

• , Если объект является корневым агрегатом, и что его собственное состояние достаточно, чтобы сказать Вам, если это допустимо или нет, Вы могли бы добавить метод проверки на нем, который располагается каскадом посредством агрегирования.

• Наконец, и я думаю, что это - Ваше основное беспокойство, если необходимо получить доступ к нескольким связанным объектам (которые не находятся в том же агрегате) гарантировать, что один из них допустим, окончательно необходимо выслать эту логику в определенном сервисе проверки.

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

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