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

Question

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

Совокупность в хранилище как ...

Сущность для ???

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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