DDD и транзакции

Обсуждаем, как правильно строить приложения
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: DDD и транзакции

Сообщение anton_z »

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: DDD и транзакции

Сообщение zelenin »

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

anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: DDD и транзакции

Сообщение anton_z »

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

Аватара пользователя
ElisDN
Сообщения: 5631
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: DDD и транзакции

Сообщение ElisDN »

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

Аватара пользователя
ElisDN
Сообщения: 5631
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: DDD и транзакции

Сообщение ElisDN »

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

Аватара пользователя
samdark
Администратор
Сообщения: 9379
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: DDD и транзакции

Сообщение samdark »

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

anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: DDD и транзакции

Сообщение anton_z »

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: DDD и транзакции

Сообщение zelenin »

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

anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: DDD и транзакции

Сообщение anton_z »

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

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

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: DDD и транзакции

Сообщение zelenin »

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
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: DDD и транзакции

Сообщение anton_z »

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: DDD и транзакции

Сообщение zelenin »

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

Ответить