vsb>>Будем считать, что очередь работает всегда и данные в ней никогда не теряются. F_>Вы же понимаете что это нереально? Сервис очередей высоконагруженный и персистентный. Последнее означает, что по CAP теореме будет низко-надежным и плохо-масштабирующимся. Читай как самой часто-ломающейся частью системы.
А почему тут вылетают A(низко-надежным) И P(плохо-масштабирующимся), если по CAP теореме наоборот должно остаться 2 из 3, а вылететь одна буква?
"Выберите 2 из 3".
vsb>>Вообще по сути вся эта машинерия очень напоминает что-то вроде state machine, где всё распределено, схема неявным образом спрятана в коде, который обрабатывает это всё. F_>Да, сага и есть такой конечный автомат, где на каждой стадии выполняется какая-то работа. Нормальные реализации паттерна Сага позволяют собрать это все в одно место, например в один класс. vsb>>3. Я когда-то сталкивался с т.н. business process management платформами. Там рисуешь процесс по блок-схеме, прописываешь действия и тд, а движок уже отвечает за то, чтобы хранить состояния, вызывать действия и тд. F_>Это реализации паттерна workflow. Но заточенные на другое.
А чем в данном контексте state machine от workflow отличается?
F_>Раньше ими решали проблему того как быстро поправить бизнес процесс если деплой приложения происходит один раз в два года.
Т.е. пропатчить dll с соотв. wf и отправить заказчику?
