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

Question

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

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

Я всегда расслаблял вещи и разрешал доступ из домена к хранилищу с помощью DI. Я не видел четких примеров того, как создать «чистый» доменный слой в сложном приложении, которое также не является анемичным и имеет сервисный / прикладной уровень, выполняющий всю грубость и беспорядок с внутренними объектами домена.

Answer 1

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

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

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

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

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

Answer 2

Я ответил на аналогичный вопрос всего несколько часов назад. Ответ содержит некоторые рекомендации, которые я использую, когда пытаюсь обогатить мою модель логикой и поведением, не загрязняя ее зависимостями, связанными с инфраструктурой. Не удается поместить реальную логику в слой домена DDD

ответ также ссылки на другие полезные ресурсы.

Удачи и не стесняйтесь написать мне или спросить меня о DDD и избегать анемичных моделей. Это интересная тема, в которой люди склонны решать эту проблему по-разному.