Если для выполнения какой-либо операции агрегату требуются некоторые данные только для чтения, которые не принадлежат ему, есть ли какие-либо негативные последствия, позволяющие хранилищу запрашивать некоторые данные из другого агрегата для создания агрегата?
Подробно:
У меня есть BC с двумя агрегатами, скажем, A и B.B требуется немного данных из A для выполнения какой-либо операции, но она никак не изменится.Данные вписываются лучше в A, поскольку существуют правила для их изменения.
Чтение IDDD и PPP DDD, кажется, что приемлемо передать временную ссылку на агрегат (или его субсубъект)другому или передать представление только для чтения в качестве объекта значения в другой агрегат.
В моем примере B не нужен весь агрегат A, а только некоторые конкретные данные, поэтомуобъект значения кажется хорошим подходом в этом случае.A может создать ВО, действующий как фабрика, ВО будет соответствовать UL, и B вообще не нужно знать о A.Бизнес-сценарий на прикладном уровне может восстановить A и B из репозиториев, сказать A для создания VO и выполнить операцию на B прохождении VO.
Предположим теперь, что восстановлениеA стоит дорого, или есть другая причина, по которой нежелательно загружать целое A для создания VO с небольшим количеством информации (возможно, данные не из одного экземпляра A, а агрегированы изсписок их или что угодно).Здесь простое решение можно было бы позволить репозиторию A создать ВО напрямую из хранилища данных.Я чувствую себя комфортно с этим и, кажется, это общий шаблон.
Но сейчас я думаю о случае, когда операция с B выполняется много раз, или, возможно, является частью более крупного вычисления B, что нужно для многих других операций.Я мог бы сослаться на VO с необходимыми данными (как частное, доступное только для чтения свойство B или где-нибудь на его графике) и позволить репозиторию B взять данные, необходимые для создания VO, и восстановить B с этим.Теперь B всегда будет иметь данные локально для выполнения своих операций.Данные, взятые из A, не могут быть изменены;сохранение B через репозиторий просто отбрасывает эти данные (возможно, оно может использовать их для обнаружения конфликтующего одновременного обновления), A и B не всегда будут согласованы, но это нормально, и перезагрузите B изрепозиторий снова запросит данные, чтобы обновить представление внутри B в случае конфликта.
Мне кажется, что этот подход приемлем, поскольку, как я понимаю, модель предметной области не связана с моделью данных, посколькухранилище, действующее как своего рода ACL между ними.Также существует единый источник правды для данных внутри A, поскольку копия внутри B является неизменной и в конечном итоге непротиворечивой.Недостатки, которые я вижу, состоят в том, что в хранилище будет больше логики (но не бизнес-логики), и что может быть неясно, откуда именно поступают данные, поскольку зависимость от B до A теперь скрыта внутри инфраструктурного кода.
Итак, вопросы таковы:
- Это не очень хороший подход в конце концов?
- Есть ли еще один недостаток, который яне вижу?
- Вы или кто-то сделал что-то подобное, чтобы я мог извлечь уроки из этого опыта?
Я знаюпример очень плохой, так как в DDD все связано с контекстом.Но с этим вопросом я сталкивался много раз в разных ситуациях.Я также знаю, что обоснованная проблема заключается в том, хорошо ли определены совокупные границы, но, допустим, они хорошо подходят для рассматриваемой проблемы.