Обойти сводный корень для редактирования отдельных моделей - PullRequest
Новая
       33

Обойти сводный корень для редактирования отдельных моделей

2 голосов
/ 24 мая 2011

Это продолжение другого вопроса: Обход объединенного корня .

Автор этого вопроса спросил, допустимо ли в этом примере обход объединенного корня.У меня тот же вопрос, но для другого варианта использования.

Наше веб-приложение имеет бэк-офис, в котором мы можем редактировать все элементы, принадлежащие объединенному корню:

  • Продукты ( Совокупный корень )
  • Параметры
  • Элементы параметров

и т. Д.

Поскольку продукт не создан свсе его опции в пакете, мы редактируем каждую сущность в совокупном корне, один за другим, на отдельном экране.Поскольку мы находимся в системе без состояний, нам необходимо однозначно идентифицировать объект, с которым мы хотим работать, в параметрах URL.Это означает, что мы, например, будем извлекать и редактировать опцию, основываясь на ее id, а не на просмотре в корне.

ИМХО, имеет больше смысла иметь репозиторий для каждого из них, ипросто сделайте: 

$optionRepository->find($optionId);

Вместо того, чтобы что-то вроде: 

foreach ($product->options as $option) {
    if ($option->id == $optionId) {
        // ok, we finally found it, we can now work on it
        // ...
        break;
    }
}

Разве это нарушает концепцию агрегированных корней из доменного дизайна?В этом случае я был бы очень признателен, чтобы узнать правильный способ сделать это.

Ответы [ 2 ]

2 голосов
/ 24 мая 2011

Это нарушает концепцию совокупного корня.Не существует «правильного» способа сделать это.Либо вы решаете просто игнорировать сводные корневые правила и обращаться к объектам напрямую, либо решаете следовать совокупным правилам и переходите к объекту из корня.Вы можете сделать это так или иначе, на самом деле больше ничего не возможно, так что нет какой-либо третьей альтернативы, которая представляет «правильный» способ как получить прямой доступ к объекту, так и подчиниться совокупным корневым правилам.

Это вопрос выбора.Лично я бы нарушил правила совокупного корня, если бы для этого была какая-то веская причина.Если список не огромен, то, что вы предлагаете, вероятно, в основном удобно.Это действительно даже так удобно?Вы должны создать и поддерживать другой репозиторий и т. Д. И т. Д.

Дело в том, что как только вы создадите этот репозиторий опций, люди будут его использовать.Где и когда.И затем есть следующий сценарий, конечно, у вас есть другие подобные ситуации.Давайте создадим еще один репозиторий.Мы сделали это там, почему не здесь тоже?Довольно скоро у вас также может быть хранилище для каждого объекта, что в конечном итоге и будет происходить в любом случае.

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

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

1 голос
/ 24 мая 2011

Если вы не будете загружать объекты из агрегатного корня, вы не сможете принудительно применить агрегатные инварианты (например, у продукта не должно быть более одной опции типа A).В результате ваши данные могут быть непоследовательными.

...