DDD и транзакции
Re: DDD и транзакции
А если один агрегат состоит из других агрегатов и у них разные репозитории, как тогда менеджить транзакцию при сохранении? Один репозиторий при этом использует другой.
Re: DDD и транзакции
агрегат - понятие контекстное. Агрегат не может состоять из других агрегатов. Это нормально, что в одном агрегате могут быть сущности, которые в другом контексте сами являются агрегатами. Но в данном контексте они не агрегаты, и соответственно сохраняются в рамках агрегата, которому принадлежат.
Re: DDD и транзакции
А, ну то есть репозиторий агрегата должен сам сохранять все сущности, без обращения к другим репозиториям
Re: DDD и транзакции
Добавьте метод saveAll(array $orders) в репозиторий, и там сохраняйте в одной транзикции.
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: DDD и транзакции
Да. И так как сделать всё транзакционным — утопия, то не рулить.Вы хотите сказать, что шину надо либо делать полностью транзакционной (все хендлеры можно откатить), либо вообще не рулить транзакциями в декораторе шины?
Нравится Yii? Давайте сделаем его лучше!.
Re: DDD и транзакции
Про правило одного агрегата. А если мне надо списать деньги с баланса пользователя и поменять статус заказа? Операция атомарная. Меняется сущность "Пользователь" и "Заказ". Под это агрегат нужен свой? Продажа? Под нее репозиторий?. Или здесь без UoW не обойдешься никак в DDD?
Re: DDD и транзакции
агрегат Order с сущностью User.
Re: DDD и транзакции
Делаю вывод: правило одного агрегата позволяет нам вынести транзакции в инфраструктурный слой.
Под правило одного агрегата можно подвести очень многое. Главное правильно обозначить границы агрегата.
Если нужно транзакционное журналирование операций, например, по требованию бизнеса, это также делается в инфраструктурном слое. Домен
ничего о внесении записи в журнал знать не должен.
Коллеги, поправьте, если я для себя сделал не точный вывод.
Интересно, а есть ли кейсы, где правило одного агрегата не работает?
Под правило одного агрегата можно подвести очень многое. Главное правильно обозначить границы агрегата.
Если нужно транзакционное журналирование операций, например, по требованию бизнеса, это также делается в инфраструктурном слое. Домен
ничего о внесении записи в журнал знать не должен.
Коллеги, поправьте, если я для себя сделал не точный вывод.
Интересно, а есть ли кейсы, где правило одного агрегата не работает?
Re: DDD и транзакции
все так
логгируете в домене, сохраняете в инфра.
это же правило бизнеса, а, значит, непосредственно доменное знание. хотя как взглянуть.
можно просто доменные эвенты сохранять для лога, или вообще на event sourcing перейти - там текущие состояния агрегатов восстаналиваются из потока событий из хранилища, а не из конечного состояния. Таким образом поток событий будет одновременно и логом.
по определению нет. если нашел кейс, то, значит, некорректно выделил контекст.
Re: DDD и транзакции
А если нужно, снять деньги, изменить статус заказа и записать в журнал, что было сделано, кем и когда. Это нужно делать в одной транзакции? Много где так делают.
Re: DDD и транзакции
в методе репозитория достаем доменные события из сущности, сохраняем сущность, сохраняем события - все в рамках одной транзакции.