Саги - это про длинные транзакции, которые мешают коротким. К распределенным отношения не имеют. А с распределенными ничего так и не придумано.

Спасибо большое за детальные пояснения.

Я пришел к таким выводам:

Интерфейс TransactionManager на уровне Application - это норм.

Инфраструктурный слой знает о всех реализациях репозиториев, поэтому должен суметь и реализовать TransactionManager.

Если для репозиториев использовать ORM (планирую Cycle ORM), то в реализации будет просто.

Давно тыкал cycle orm. Позволяет ли он делать внутри value object ссылки на другие entity сейчас?

не пробовал такое, не подскажу(

> Due to space limitations, we only discuss sagas m a centralized system, although clearly they can be implemented m
a distributed database system

Именно так. Саги неспецифичны для рапсределенных транзакций и не имеют отношения к решению их проблем.

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

Разумеется что я не противопоставляю их - саги идут со своими недостатками, потому и оговорки что должны быть дополгительные нефункциональныет ребования.

Про OTS почитаю. интересно. Я с COBRA вообще не сталкивался, только оч поверхностно

завидую ) корба ебучая жесть

не просто так из всего того что изобрели в 80-х и 90-х она не на слуху)

однако она повлияла немного потому интересно разобраться че откуда пошло

CORBA - попытка делать облачные сервисы без облачной инфраструктуры. on premise же стоил заоблачных денег. Но в плане спецификаций там все хорошо.

а в плане разработки там все печально, девелопер экспириенс ужасен

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

На С++ много boilerplate кода и всяческих кастов. На Яве вроде норм, если внешне.
Забавно, что тогда еше шли дискусс о неоптимальности передачи и обработки строк вместо бинарных протоколов.

ну да, та же SOA, только не на базе веб-протоколов. Те же "микросервисы", которые после ужасной производительности укрупнялись в просто сервисы.

То зато IDL, а это огромный шаг

я не очень понял как это применить в случае транзакций....

сделать некий TransactionHandler::run(), в который будет передаваться колбэк, который будет выполнен в рамках одной транзакции?

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