В DDD нормально ли, что объекты модели предметной области имеют доступ к своим репозиториям?

В настоящее время я разрабатываю и реализую структуру с использованием Domain Driven Design концепций.

Я пытаюсь поместить Validation в слой модели предметной области.

Иногда для проверки требуется доступ к базе данных и запрос к ней, например:

"querying to check multiple column unique index"

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

Интересно, можно ли для объектов домена иметь доступ к репозиториям?

И если это не нормально, то как поступить с этой ситуацией?

Я имею в виду, следует ли перенести такие методы проверки на repository или Application Service слои? Если да, можно ли переместить методы проверки на эти уровни?

Или, поскольку службы домена могут иметь доступ к репозиториям, следует ли нам создавать domain services в domain model layer для проверки?

Как нам с этим справиться?

заранее спасибо


architecture domain-driven-design ddd-repositories
person gwt    schedule 03.01.2017    source источник
comment
Возможный дубликат Допускается ли доступ сущностей к репозиториям?   -  person guillaume31    schedule 03.01.2017
comment
@ guillaume31 Я не думаю, что это то же самое, что вы упомянули, и я отредактировал свой вопрос и добавил больше деталей. Любые решения будут оценены!   -  person gwt    schedule 03.01.2017
comment
Какой именно инвариант нужно проверить? О каком агрегированном корне идет речь и почему он должен проверять эту уникальность? Проверка уникального индекса с несколькими столбцами - это не очень много описания домена ...   -  person guillaume31    schedule 03.01.2017
comment
ваш заголовок Q в точности совпадает с заголовком Q, с которым я связался   -  person guillaume31    schedule 03.01.2017
comment
Я пытаюсь разместить проверку на уровне модели предметной области, чтобы справиться со всеми сложностями, которые иногда могут возникнуть при проверке! например, проверка сложной доменной службы, такой как подача производственной линии, - это очень сложный процесс, если вы знаете. А проверка уникальности - это еще одно условие, при котором необходимы запросы. В таких условиях бывает, что вам может потребоваться запросить базу данных, поэтому вам потребуется доступ к репозиторию для нее.   -  person gwt    schedule 03.01.2017
comment
Так как же поступать в таких ситуациях?   -  person gwt    schedule 03.01.2017
comment
Это зависит от вашего контекста и домена. Нет точного и быстрого ответа, пока мы не знаем контекста.   -  person guillaume31    schedule 03.01.2017
comment
Я знаю, что проверка уникального индекса с несколькими столбцами - это не большая часть описания домена, но это необходимость проверки, которую необходимо проверить перед добавлением объекта в базу данных, и если вы хотите разместить проверку на уровне модели домена, поэтому ее следует проверить там .   -  person gwt    schedule 03.01.2017
comment
кто отрицает какие-либо комментарии?   -  person gwt    schedule 03.01.2017
comment
Несколько существующих вопросов, ответы на которые на каком-то уровне верны: stackoverflow.com/questions/998317/, stackoverflow.com/questions/2660817/. Также ознакомьтесь с thinkbeforecoding.com/post/2009/10 / 28 /   -  person guillaume31    schedule 03.01.2017
comment
@ guillaume31 спасибо. как говорит Самуэль в stackoverflow.com/questions/998317/ Одна из возможностей - сделать то же самое, что я упомянул. добавление метода в репозиторий, например: GetByName (), где Name должно быть уникальным, а затем вызвать этот метод из класса Model. Это решение требует, чтобы модель имела ссылку на репозиторий. Итак, по вашему мнению, это нормально?   -  person gwt    schedule 03.01.2017
comment
Это может зависеть от вашего контекста, но вы должны знать, что могут возникнуть условия гонки, и теперь объект имеет нечистую зависимость от конкретного репозитория, который должен быть каким-то образом передан ему.   -  person guillaume31    schedule 04.01.2017
comment
Обычно мне больше нравится решение из блога thinkbeforecoding, но тогда YMMV в зависимости от вашего домена   -  person guillaume31    schedule 04.01.2017

Ответы (1)


arrow_upward
4
arrow_downward

Интересно, можно ли для объектов домена иметь доступ к репозиториям?

Не совсем - это создает путаницу зависимостей между вашими компонентами.

Архитектурное ожидание состоит в том, что агрегат при загрузке имеет всю информацию о состоянии, необходимую для защиты своего инварианта. Любое другое состояние, участвующее в модификации агрегата, должно передаваться в качестве аргумента.

Таким образом, необходимость запроса чего-либо за пределами совокупной границы предполагает, что в вашем дизайне есть недостаток (ограничение, которое вы пытаетесь наложить, не является «реальным», совокупная граница нарисована не в том месте и т. Д.).

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

Приемлемой альтернативой, которая может соответствовать вашим потребностям, является получение приложением необходимых данных из репозитория, а затем передача представления этих данных (или службы домена, которая предоставляет доступ к этим данным) агрегату, который затем может использовать это для «проверки».

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

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

person VoiceOfUnreason    schedule 03.01.2017
comment
Большое спасибо. Что, если экземпляр репозитория передается сущностям домена с вышележащих уровней с помощью внедрения конструктора? Вроде как это сделано для доменных служб. - person gwt; 06.01.2017
comment
@VoiceOfUnreason У меня сейчас почти такая же проблема. AR содержит коллекцию объектов-значений, это большая коллекция, и объект-значение также является большим объектом. Но объект значения содержит идентификатор, поэтому вместо этого я заставляю AR содержать идентификатор объекта значения. AR реализует логику для поиска некоторой идентичности объекта-значения из коллекции идентификаторов, а также нуждается в деталях найденного объекта-значения, поэтому как я могу решить эту проблему? - person YonF; 20.08.2018
comment
Если объект внедряется с любым другим компонентом, он концептуально теряет свой статус модели предметной области. Каким бы интригующим ни было предоставление модели предметной области прямого доступа к ее репозиторию, не делайте этого. Модели предметной области буквально занимаются только своим делом. - person Arman; 22.09.2020