DDD - правило, согласно которому сущности не могут получить прямой доступ к хранилищам - PullRequest
156 голосов
/ 17 апреля 2011

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

Это из книги Эрика Эванса Дизайн, управляемой доменом , или откуда-то еще?

Где за этим есть хорошие объяснения?

edit: уточнить: я не говорю о классической ОО практике разделения доступа к данным на отдельный уровень от бизнес-логики - я говорю о конкретной договоренности, согласно которой в DDD сущности не должнывообще говорить со слоем доступа к данным (то есть они не должны содержать ссылки на объекты репозитория)

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

обновление: март 2013 года, голосование по этому вопросу подразумевает, что в этом есть большой интерес, и хотя он былмного ответов, я все еще думаю, что есть место для большего, если у людей есть идеи по этому поводу.

Ответы [ 12 ]

0 голосов
/ 07 ноября 2013

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

0 голосов
/ 09 июля 2012

Это из книги Эрика Эванса «Управление доменом» или из другого места?

Это старые вещи.Книга Эрика только что заставила ее гудеть немного больше.

Где есть хорошие объяснения причин, стоящих за ней?

Причина проста - человеческий разум становится слабымкогда он сталкивается со смутно связанными множественными контекстами.Они приводят к неоднозначности (Америка в Южной / Северной Америке означает Южную / Северную Америку), неоднозначность приводит к постоянному отображению информации всякий раз, когда разум «дотрагивается до нее», что приводит к плохой производительности и ошибкам.

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

По аналогии: если вы изучаете, как писать от руки, вы не должны быть обременены пониманием того, где было сделано перо, почему чернила держатся на бумаге, когда была изобретена бумага и каковы другие известные китайские изобретения.

править: Чтобы уточнить: я не говорю о классической ОО практике разделения доступа к данным на отдельный уровень от бизнес-логики - я говорю о конкретной договоренности, согласно которой в DDD,Субъекты вообще не должны взаимодействовать со слоем доступа к данным (то есть они не должны содержать ссылки на объекты репозитория)

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...