Как смоделировать порядок сортировки «многие к одному» по двум сводным корням

Таким образом, Продукт и Релиз являются AR. Выпуск связан с продуктом через AggregateId. Вы хотите получить список всех релизов для данного продукта, заказанного чем-то?

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

Я бы просто создал ReleaseQueryService, который принимает productId и параметр заказа и вызывает ReleaseRepository.loadOrderedReleasesForProduct(productId, order).

Я бы также подумал о разделении контекстов, может быть, модель для презентации релиза должна быть в другом контексте? В примере дополнительные AR ProductReleases, которые будут использоваться только для запросов.

Я обнаружил, что на самом деле лучше всего создать новый общий корень (например, ProductReleaseSorting, как предлагается) для каждой отдельной сортировки и/или упорядочения. Это связано с тем, что releaseOrder явно не является свойством Product, то есть чем-то, что само по себе имеет значение для продукта. Скорее, это свойство "представления" для коллекции продуктов, и это представление должно быть смоделировано отдельно.

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

Если теперь вы обрабатываете сортировку менеджера по продукту в совокупности ProductReleaseSorting, вы

1. иметь единый источник достоверной информации для заказа (AR),
2. ProductReleaseSorting AR может ввести такие ограничения, как отсутствие двух продуктов с одинаковым номером заказа, и вы
3. не сталкивайтесь с проблемой обновления нескольких AR в одной транзакции при изменении порядка.

Обратите внимание, что ваш агрегат ProductReleaseSorting, скорее всего, имеет уникальный идентификатор ("Singleton") в вашем домене, т. е. все менеджеры продуктов имеют одинаковую сортировку. Однако, если все члены команды хотели бы иметь свой собственный ProductReleaseSorting, это можно легко поддержать, присвоив ProductReleaseSorting соответствующий идентификатор. Точно так же более общий ProductSorting можно получить по идентификатору для каждой команды (маркетинг или управление продуктами) из репозитория. Все это легко сделать с новым отдельным сводным корнем для упорядочивания, но сложно, если вы добавите свойства к базовым элементам/сущностям.