DDD Repository Осведомленность о других хранилищах

Question

В целом допустимо ли, что один репозиторий может получить доступ к другому репозиторию? В частности, в этом случае у меня есть один сводный корень, который использует другой совокупный корень, чтобы определить, какие сущности добавить. Это соответствует линиям Item / Item Type. Причина того, что тип элемента является совокупным корнем, заключается в том, что они могут обслуживаться отдельно в рамках инструмента управления вне области действия какого-либо отдельного элемента.

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

Изменить - Дополнительная информация:

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

Answer 1

Я думаю, это сводится к тому, что вы пытаетесь сделать. Если это своего рода этап проверки (например, удалить все элементы с типами элементов, срок действия которых истек), вы можете утверждать, что он относится к уровню обслуживания или спецификации. Исходя из языка, который вы используете (то есть «определите, какие сущности добавить»), он, кажется, предлагает последнее, хотя трудно сказать без подробностей.

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

С другой точки зрения кажется, что между вашими совокупными корнями есть размытие, которое может указывать на то, что работают два разных контекста. Например, можно утверждать, что инструмент управления формирует отдельный ограниченный контекст для вашего основного приложения, и поэтому случай для типа Item, являющегося агрегированным корнем, на самом деле не применим. например Инструмент управления может интересоваться только типами элементов (а не элементами), в то время как ваше основное приложение может рассматривать типы элементов как более значимый объект, чем объект.

Обновление

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