Yii Framework

А если один агрегат состоит из других агрегатов и у них разные репозитории, как тогда менеджить транзакцию при сохранении? Один репозиторий при этом использует другой.

anton_z писал(а): ↑2017.01.16, 16:22 А если один агрегат состоит из других агрегатов и у них разные репозитории, как тогда менеджить транзакцию при сохранении? Один репозиторий при этом использует другой.

агрегат - понятие контекстное. Агрегат не может состоять из других агрегатов. Это нормально, что в одном агрегате могут быть сущности, которые в другом контексте сами являются агрегатами. Но в данном контексте они не агрегаты, и соответственно сохраняются в рамках агрегата, которому принадлежат.

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

anton_z писал(а): ↑2017.01.16, 15:52 Про правило одного агрегата слышал. А как же быть со всякими групповыми операциями, охватывающими более одного агрегата? Например, сразу отменить 10 заказов - пользователь отмечает галочками и жмакает на кнопку.

Добавьте метод saveAll(array $orders) в репозиторий, и там сохраняйте в одной транзикции.

anton_z писал(а): ↑2017.01.16, 16:40 А, ну то есть репозиторий агрегата должен сам сохранять все сущности, без обращения к другим репозиториям

Да, если сущности связанные, то всё дерево сохраняется одним репозиторием в одной транзакции.

Вы хотите сказать, что шину надо либо делать полностью транзакционной (все хендлеры можно откатить), либо вообще не рулить транзакциями в декораторе шины?

Да. И так как сделать всё транзакционным — утопия, то не рулить.

Про правило одного агрегата. А если мне надо списать деньги с баланса пользователя и поменять статус заказа? Операция атомарная. Меняется сущность "Пользователь" и "Заказ". Под это агрегат нужен свой? Продажа? Под нее репозиторий?. Или здесь без UoW не обойдешься никак в DDD?

агрегат Order с сущностью User.

Делаю вывод: правило одного агрегата позволяет нам вынести транзакции в инфраструктурный слой.
Под правило одного агрегата можно подвести очень многое. Главное правильно обозначить границы агрегата.
Если нужно транзакционное журналирование операций, например, по требованию бизнеса, это также делается в инфраструктурном слое. Домен
ничего о внесении записи в журнал знать не должен.

Коллеги, поправьте, если я для себя сделал не точный вывод.

Интересно, а есть ли кейсы, где правило одного агрегата не работает?

anton_z писал(а): ↑2017.01.17, 14:24 Делаю вывод: правило одного агрегата позволяет нам вынести транзакции в инфраструктурный слой.
Под правило одного агрегата можно подвести очень многое. Главное правильно обозначить границы агрегата.

все так

anton_z писал(а): ↑2017.01.17, 14:24Если нужно транзакционное журналирование операций, например, по требованию бизнеса, это также делается в инфраструктурном слое.

логгируете в домене, сохраняете в инфра.

anton_z писал(а): ↑2017.01.17, 14:24Домен ничего о внесении записи в журнал знать не должен.

это же правило бизнеса, а, значит, непосредственно доменное знание. хотя как взглянуть.
можно просто доменные эвенты сохранять для лога, или вообще на event sourcing перейти - там текущие состояния агрегатов восстаналиваются из потока событий из хранилища, а не из конечного состояния. Таким образом поток событий будет одновременно и логом.

anton_z писал(а): ↑2017.01.17, 14:24Интересно, а есть ли кейсы, где правило одного агрегата не работает?

по определению нет. если нашел кейс, то, значит, некорректно выделил контекст.

А если нужно, снять деньги, изменить статус заказа и записать в журнал, что было сделано, кем и когда. Это нужно делать в одной транзакции? Много где так делают.

anton_z писал(а): ↑2017.01.17, 15:08 А если нужно, снять деньги, изменить статус заказа и записать в журнал, что было сделано, кем и когда. Это нужно делать в одной транзакции? Много где так делают.

в методе репозитория достаем доменные события из сущности, сохраняем сущность, сохраняем события - все в рамках одной транзакции.