Осведомленность о репозитории DDD о других репозиториях

Question

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

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

РЕДАКТИРОВАТЬ - Дополнительная информация:

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

Answer 1

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

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

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

Обновлять

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