Ну и код в cadence обычно выглядит гораздо понятнее, нежели в реализациях через сагу (пример выше очень показателен)

Cadence от убера, конечно, избыточно сложен, но написать свой собственный не очень сложно...

Ну у них вообще официально заявлено saga orchestration и даже example показательный есть

Официально - да. Но подход сильно другой. И кстати компенсации писать на каденсе не удобно (впрочем, они обычно и не нужны).

"Они обычно и не нужны" очень смелое заявление ) несколько раз помогал на  camunda сагу делать, из-за легких компенсаций люди терпели проблемы с производительностью )))

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

Не компенсации. Камунда не очень производительна под большой нагрузкой, когда есть определённый sla на ответ. Но она и не для этого. Люди использовали ее для реализации саги, чтобы легко рисовать flow и компенсации.

А, ну не надо комунду использовать для таких задач.
Я про то, что при оркестрации задачи компенсации не самые популярные.
Скорее процесс нужно "додавить", нежели "откатить".
И откат нужен только если додавить не получается.

Ну понятно что не надо 😁 речь же как раз о том, что потребность в саге с компенсациями есть. И не мне судить реальная ли она или высосана из пальца. Есть ТЗ, по нему нужно откатить 🙂

Э, я обычно сам пишу ТЗ и стараюсь глупости туда не добавлять )
Потребность есть и на схемах типа cadence она реализуема. Но фокус там не на "откате", а не "дожатии без проблем".
И это сильно отличает от обычной саги.

На самом деле удобнее вообще говорить об "разных путях прохождения бизнес-процесса", где "компенсация" - один из вариантов.
И вот для такого подхода оркестрация в стиле cadence очень удобна.
Хотя плохо масштабируема, конечно.

Мне нравится говорить о спрямлении бизнес процессов.

То есть нужно включить голову, чтобы постараться выстроить процесс без циклов.

При этом, компенсации можно рассматривать как альтернативные сценарии (подпроцессы).

Как мне кажется, идеальный процесс должен стремиться к DAG.

То есть нужно учиться выражать процессы в виде DAG, всегда, где это возможно.

Если это получается, очень удобно использовать потоковую обработку.

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

Всем доброго времени суток! Работаю сейчас над курсовой работой, по теме модернизация образовательных учреждений. В рамках работы внедряю видеоконференцсвязь, систему машинного зрения с контролем посещаемости и внимания на семинарах и систему контроля экзаменуемых.  Сейчас собираю материал для описания архитектуры типового университета и бизнес-процессов как они есть на данный момент. Может у кого-нибудь есть материал на эту тему, источники или рабочие инсайты, буду очень рад если поделитесь) заранее спасибо!

Не всегда конечно. Но вообще, интересно работать в такой парадигме. Причём, если команда уловила суть, она будет работать с бизнесом над процессами. Постоянная работа над процессами.

Кстати, посмотрел вилки в вакансиях. Мне кажется, мы приближаемся к дну.

Судя по вилкам в большинстве вакансий, архитектура воспринимается как дно.

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

Точно. И бизнес часто готов на это, если это бизнес.

А что за история у них с форком произошла? https://stackoverflow.com/a/61281435

Понятия не имею. Я cadence не использую, мы свое написали