Репозиторий для типов значений или сущностей в доменно-ориентированном дизайне

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

Агрегировать в репозиторий как ...

Объект находится в ???

Значение равно ???

В моем конкретном сценарии у меня есть репозиторий для объекта продукта в контексте маркетингового веб-сайта.

Продукт - это совокупность сущностей маркетинговой информации ProductInfo (Aggregate Root), List of ProductSpecs и ShippingInfo, а также списка ссылок на значения RelatedProduct для других ограниченных контекстов.

Теперь в моем репозитории мне нужно собрать вместе данные из разных сущностей и объектов значений, чтобы создать совокупный корень.

Я получаю ProductInfo (root) и RelatedProducts (значение) из CMS. ProductSpecs (entity) и ShippingInformation (entity) берутся из rest apis (микросервисы, которые обрабатывают другие ограниченные контексты).

В моей первой попытке я создал репозитории / интерфейсы / pocos домена для всех сущностей, а затем заставил слой пользовательского интерфейса сопоставить их с моделями просмотра для отображения. По сути, создание агрегата для каждой сущности, однако сущности имеют форму объектов доступа к данным (потому что на данный момент они есть), и эти проблемы просачиваются в мой домен. Если и когда мы обесценим Shipping Api и перенесем его в CMS, мне придется удалить и обновить репозитории / интерфейсы, а затем обновить все на уровне пользовательского интерфейса, который затрагивает все это, потому что я изменил местоположение, где я что-то хранил.

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

Мне нужна моя CMS и логика запросов Api в отдельных проектах / dll, чтобы их можно было повторно использовать, мне нужен репозиторий, который объединяет объекты доступа к данным для создания агрегатов. Как назвать классы в проектах запросов CMS и Api? Есть ли название для шаблона, который мне следует использовать?


architecture aggregate entity domain-driven-design ddd-repositories
person WhiteleyJ    schedule 30.05.2019    source источник
comment
Насколько я понял из вашего вопроса, вы смешиваете уровень домена и инфраструктуру вместе, что неверно. Прежде всего, вы должны спроектировать уровень домена, а после этого для получения или публикации данных на уровне инфраструктуры вы можете использовать API или CMS или что-то еще. Я думаю, что вы склонны подстраивать объекты домена под инфраструктуру, а в DDD это неправильно.   -  person Ali Soltani    schedule 02.06.2019
comment
А концепции DDD, такие как сущность и значение, применяются исключительно к уровню домена.   -  person Nate T    schedule 14.06.2021

Ответы (1)


arrow_upward
1
arrow_downward

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

Шаблон репозитория Эрика Эванса в его книге DDD является хорошим примером этой стратегии. Я могу только догадываться, что он ввел шаблон репозитория вместо более общей инверсии принципа управления, потому что это наиболее распространенный случай использования технологии для сохранения объектов.

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

Это единственный способ, которым ваши корневые агрегаты могут взять на себя ответственность за постоянное управление согласованным состоянием в пределах своих границ. Эрик говорит здесь о хранении инвариантов.

Все идет нормально. Теперь вы подошли к уродливой части. Если вы моделируете свои агрегаты так, как они лучше всего подходят для вашего домена, вам придется решить проблему сопоставления модели предметной области с конкретной моделью / технологией базы данных. Это называется несоответствием объектного импеданса. Объектно-реляционные преобразователи (ORM), такие как JPA, Hibernate и т. Д., Должны решить эту проблему за вас, но проблема остается в том, что это может быть громоздкой и сложной частью.

Тем не менее, вы должны скрыть все эти уродливые вещи в реализации репозитория. Вам понадобятся их DAO, объекты JEE, менеджеры объектов. Что бы ни. Но вы никогда не раскрываете их за пределами интерфейса репозитория.

Напоследок я расскажу о вашей теме графического интерфейса. Кто использует домен со всеми его мелкозернистыми элементами модели? Обычно только уровень приложения, который формулирует команды на основе пользовательского ввода и предоставляет представления для пользовательского вывода. Вы можете думать о прикладном уровне как о переводчике между графическим интерфейсом пользователя и доменом. По этой причине вы предоставляете графическому интерфейсу некоторую медленно изменяющуюся и долгосрочно стабильную модель и можете быстро вносить изменения в свою модель.

Надеюсь это поможет

person Frank S.    schedule 27.07.2019