DDD: совокупный основной вопрос
"Есть ли жесткое правило для этого?" - По-видимому, не, так как Вы нашли примеры обоих.
Для общей непротиворечивости, я сказал бы, что стрелка должна подчеркнуть для возрастания, вниз для убывания. Это согласовывается с Windows (нажмите заголовок столбца в Проводнике), и Office (фильтруют/сортируют столбец в Excel).
3 ответа
Если вы хотите выбрать из списка Bars, где они не связаны с Foo, то это не совокупный корень. Например, вы не можете получить список OrderItems без их Order, поэтому это единый агрегированный корень (Order), но вы можете получить список продуктов для назначения OrderItems, поэтому Product не является частью агрегированного root Order.
Обратите внимание, что хотя OrderItem является частью совокупного корня Order, вы все равно можете создавать и обновлять его независимо. Но вы не можете получить его без ссылки на Заказ. То же самое для вашего Bar, даже если он был частью Foo, вы могли бы получить каждый (Foo.Bars) и работать с ним, или сделать Foo.AddBar (new Bar ()). Но если вам нужно получить List без Foo, Bar не является частью агрегата Foo. Это отдельная сущность.
Ну, вот как я вижу здесь DDD, но я, конечно, не Эрик Эванс.
Причины наличия агрегированных корней:
- Они обеспечивают управляемый и направленный доступ к составным объектам
- Они могут применять правила, гарантирующие, что весь агрегат действителен
Мое мнение :
Если вам нужно выбрать объекты Bar без Foo , используйте BarRepository .
Но ...
Что, если вы обновите Bar , и это нарушит правило проверки для его родительского Foo ? Если это могло произойти, вы должны получить доступ к Bar через его родительский Foo .
Если, однако, вам нужно получить доступ к группе объектов Bar (например, для пакетного задания или отчета), и вы знаете , что Foos не сломается, продолжайте и получите доступ к ним через BarRepository .
Помните, что совокупные корни могут состоять из других совокупных корней. Вы можете обнаружить, что Bar сам по себе является совокупным корнем, что дает вам основания для BarRepository :)
Вы уверены, что Бар должен быть сущностью? Есть ли необходимость его отслеживать и менять в домене? Если вы можете рассматривать его как объект значения, я бы посоветовал вам получить его из службы, а затем «подключить» выбранный объект значения к сущности Foo. Для мгновенного использования через раскрывающийся список.