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

Саги это круто но не надо фанатизм врубать

Cqrs сильно усложняет ui и вынуждает тебя довольно сложные вещи делать. Это оправдано там где без этого сложнее

Попробуй на cqrs с сагами сделать такую фичу как "регистрация пользователя с уникальным email". Ты сможешь это сделать но выйдет оч сложно. Довольно редко это может быть оправдано для такой примитивной фичи

Тоестт все отличие, что ответ от сервис лейера можно получить в том же запросе? А в саге только ридмодельку дёргать?

Помоему мы обсуждаем одну из возможных реализаций саги, а не как концепт

если оно читает с той же базы которая для логики используется
то не вижу какого то особого услажнения с CQRS даже проще
Прикуртил RQL и запрашиваешь что надо без дополнительного кода (ну или вообще hasura/postgrestrest). Никаких ДТО порятнок и прочей дичи

При этом нет гарантий когда твоя Рид моделька обновится.

Вся суть и сложность CQRS в том что ты должен команды выбирать таким образом что бы "они никогда не могли фэйлиться по бизнес причинам". Мол что бы на клиенте можно было рид модельку обновлять с ассампшеном что предыдущий стэп когда-нибудь да выполнится. За счет этого можно получить оч отзывчивую систему хоть под копотом там твоя команда из-за крэша базы 2 минуты выполнялась

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

и даже если есть 0.1% ситуаций когда команда все ж может зафэйлиться - то просто присылаешь потом пользователю "сорян не вышло начинай по новой".

Сага она ничего не дергает, она принимает и отправлет сообщения и это все что она делает для внешнего мира

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

Что бы саги работали тебе по хорошему нужны ретраи еще для разруливания всяких там out of order доставок. Это уже тянет инфраструктуру весьма приличную

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

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

для них нет ограничений на количество и вид зависимостей.

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

То есть от других сервисов тоже может зависеть?

опять же, вопрос реализации. В JS с их нативным эвентлупом это вообще не проблема, если есть пуши

конечно. Просто выглядеть код должен как-то типа...

DoMyVeryImportantUseCase(DoStuff command) {
    val firstThing = firstRepo.get(command.firstThingId)
    val secondThing = secondRepo.get(command.secondThingId)
    val fee = feeCalculation(command.amount)
    // ...
}

мол просто линейно дергаем разные штуки