Может быть, для некоторых объектов реализации доменной логики требуется доступ к репозиторию для обновления/удаления себя или любого связанного объекта. Это правильно звучит??
могут ли модели домена знать о репозиториях?
Ответы (2)
Нет, по крайней мере, для вопроса, помеченного тегом "domain-driven-design". Определенно, паттерн Active Record имеет право жить в некоторых системах, и некоторые люди находят сильную связь полезной, но в DDD предлагается способ использовать репозитории явно:
Evans DDD, стр. 152. Для каждого типа объекта, которому требуется глобальный доступ, создайте объект, который может обеспечить иллюзию коллекции в памяти всех объектов этого типа. «...» Предоставляйте РЕПОЗИТОРИИ только для ОБЪЕДИНЕННЫХ корней, которым действительно нужен прямой доступ. Сосредоточьте внимание клиента на модели, делегируя хранение всех объектов и доступ к РЕПОЗИТОРИЯМ.
Итак, в DDD репозиторий инкапсулирует не только код инфраструктуры, необходимый для доступа к базе данных, но и всю идею того, что объекты должны храниться и загружаться.
Если вы выполняете сложные действия, включающие сохранение и загрузку из базы данных, то лучшими кандидатами являются сервисы, имеющие ссылки на репозитории.
person
Boris Treukhov
schedule
05.08.2012
спасибо Борис за этот ответ, возможно, мне следует немного подробнее остановиться на том, откуда этот вопрос, пожалуйста, посмотрите на этот вопрос, который объясняет мой сценарий stackoverflow.com/questions/11643636/soft-delete-in-ddd и дайте мне знать, что вы думаете
- person redzedi; 06.08.2012
а также, поскольку вы упомянули об этом, я продолжаю слышать это мнение о DDD, в котором говорится, что не используйте DDD, если вы делаете обычное приложение CRUD. Я считаю, что некоторые из общих рекомендаций DDD универсальны независимо от того, разработал ли я вездесущий язык или нет (я думаю, что всегда есть UL, хотя словарь состоит из довольно технических терминов, таких как Insert, Update, DElete — например, мой эксперт по предметной области на самом деле использует эти термины :) )
- person redzedi; 06.08.2012
Ответ @redzedi pein в порядке, я бы просто ввел поле состояния (или состояния) для объекта, и у объекта был бы метод отмены (), который изменит его статус на ОТМЕНА, имхо это не имеет ничего общего с репозиторием CRUD-методы. Конечно, когда кто-то отменяет счет или что-то еще, он будет сохранен с помощью метода Save().
- person Boris Treukhov; 06.08.2012
Эванс утверждает где-то в своей книге, что не будет существовать ни одного проекта, который использует все практики из книги, поэтому вы не можете реализовать систему на 100% ddd - в любом случае это вопрос баланса и здравого смысла.
- person Boris Treukhov; 06.08.2012
@redzedi Я видел ваш недавний вопрос, поэтому, пожалуйста, проверьте другой ответ Я не думаю, что есть какие-либо преимущества в том, чтобы прилагать большие усилия для адаптации фреймворков, потому что всегда есть риск в конечном итоге разработать экспертная система :-)
- person Boris Treukhov; 06.08.2012
Хотя для организации определенно кажется опасным иметь доступ к собственному репозиторию для сохранения или удаления себя (см. игнорирование сохраняемости), в некоторых случаях я мог допустить, что объект в исключительных случаях запрашивает из репозитория другой совокупный корень, на который он еще не содержит ссылку.
Однако обратите внимание, что объекты предметной области должны знать только об абстракциях репозиториев (т. е. об интерфейсах, находящихся на уровне предметной области), а не об их конкретных реализациях. Поэтому не делайте так, чтобы уровень домена ссылался на уровень инфраструктуры, а вместо этого внедряйте экземпляры конкретных репозиториев во время выполнения, когда они вам нужны.
И в любом случае это не должно быть нормой.
person
guillaume31
schedule
07.08.2012
