DDD: совокупный корневой вопрос

Если вы хотите выбрать из списка Bars, где они не связаны с Foo, то это не совокупный корень. Например, вы не можете получить список OrderItems без их Order, поэтому это единый агрегированный корень (Order), но вы можете получить список продуктов для назначения OrderItems, поэтому Product не является частью агрегированного корня Order.

Обратите внимание, что хотя OrderItem является частью совокупного корня Order, вы все равно можете создавать и обновлять его независимо. Но вы не можете получить его без ссылки на Заказ. То же самое для вашего Bar, даже если он был частью Foo, вы могли бы получить каждый (Foo.Bars) и работать с ним, или сделать Foo.AddBar (new Bar ()). Но если вам нужно получить List без Foo, Bar не является частью агрегата Foo. Это отдельная сущность.

Ну, вот как я вижу здесь DDD, но я, конечно, не Эрик Эванс.

Причины наличия совокупных корней:

1. Они обеспечивают контролируемый и направленный доступ к составным объектам.
2. Они могут применять правила, чтобы гарантировать, что весь агрегат действителен.

Мое мнение: Если вам нужно выбрать Bar объекты без Foo, используйте BarRepository.

Но ... Что, если вы обновите Bar, и это нарушит правило проверки для своего родительского Foo? Если это могло произойти, вы должны получить доступ к Bar через его родительский Foo.

Однако, если вам нужно получить доступ к группе Bar объектов (например, для пакетного задания или отчета), и вы знаете, что Foos не сломается, продолжайте и обращайтесь к ним через BarRepository.

Помните, что совокупные корни могут состоять из других совокупных корней. Вы можете обнаружить, что Bar сам по себе является совокупным корнем, что дает вам оправдание для BarRepository :)

Вы уверены, что Бар должен быть юридическим лицом? Есть ли необходимость его отслеживать и менять в домене? Если вы можете рассматривать его как объект значения, я бы посоветовал вам получить его из службы, а затем «подключить» выбранный объект значения к объекту Foo. На мгновение через раскрывающийся список.