Event-sourcing и sagas - компенсационные транзакции

Первый вопрос о SO (правда ???), так что потерпите меня, пожалуйста :)

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

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

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

Другими словами, как можно попытаться компенсировать событие, которое не является последним в потоке событий определенного совокупного корневого (говоря на жаргоне EventStore)?


cqrs event-sourcing domain-driven-design distributed-transactions
person tdaliviu    schedule 24.09.2015    source источник
comment
Я предполагаю, что вы можете полагаться либо на информацию о событии, либо на саму дополненную реальность, чтобы увидеть, может ли все еще произойти компенсирующее действие. Если нет, то вы можете запустить процесс, требующий ручного разрешения конфликта.   -  person plalx    schedule 25.09.2015

Ответы (1)


arrow_upward
2
arrow_downward

Это довольно сложная ситуация, поскольку я вижу, что вы можете получить недопустимый AR после вашей компенсирующей записи, что сделает ваше компенсирующее действие недействительным.

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

Другой подход может заключаться в предотвращении определенных команд на вашем AR, если он находится в определенном состоянии, которое указывает на то, что это может привести к проблемам для этих команд. Тогда пользователь не сможет выполнять эти команды. Ваш менеджер процессов позаботится о этом состоянии, а также об истечении срока действия / тайм-аутах и ​​т. Д.

person Eben Roux    schedule 25.09.2015
comment
Спасибо за ответы. Хотя у меня есть несколько комментариев. Ваше первое предложенное решение очень похоже на блокировку, что, вероятно, приведет к проблемам с производительностью. Второе предложение предполагает, что AR будут гностически относиться к своему участию в саге, что, на мой взгляд, противоречит принципу саги, согласно которому только сага знает детали оркестровки, а AR просто вызываются. - person tdaliviu; 25.09.2015
comment
Я не думаю, что сохранение значений для последующего использования вообще очень похоже на блокировку :) Второй вариант может потребоваться только для того, чтобы заставить сагу работать, но если это беспокоит, тогда может потребоваться другое решение . Раньше я использовал довольно много данных в диспетчерах процессов, где состояние характерно только для диспетчера процессов. Но, как я уже упоминал, это непростая ситуация. Лучше всего держаться подальше от ваших живых AR, пока вы не будете уверены, что изменения могут быть применены безопасно. - person Eben Roux; 25.09.2015
comment
Я подумал об этом и не знаю, сообщает ли использование какого-либо «статуса» в AR о диспетчере процессов. Возьмем, к примеру, Order, он определенно имеет некоторый статус для своего жизненного цикла, но он связан с бизнес-процессом. Таким образом, он не обязательно связан с менеджером процессов, но он определенно осведомлен о какой-либо форме бизнес-процесса. - person Eben Roux; 25.09.2015
comment
Извините, я не получил первую часть вашего ответа с самого начала - конечно, сохранение некоторых временных данных не блокирует, мое плохое. Я согласен с вашей точкой зрения о том, что изменения следует сохранять только тогда, когда это безопасно, но включение состояния, связанного с сагой, в AR бросит вызов сагно-агностическому аспекту самих AR. Также AR может участвовать в нескольких сагах в разных контекстах. Общий вопрос все еще остается в силе - существует ли какая-либо модель наличия распределенной транзакции без транзакции как таковой при работе в параллельной среде? - person tdaliviu; 25.09.2015