Size: a a a

Software Design/Architecture/Zen

2021 January 15

SP

Sergey Protko in Software Design/Architecture/Zen
Распределенные Локи тоже можно юзать - при небольших нагрузках это в целом рабочий вариант
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Саги это круто но не надо фанатизм врубать
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Cqrs сильно усложняет ui и вынуждает тебя довольно сложные вещи делать. Это оправдано там где без этого сложнее
источник

SP

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

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Тоестт все отличие, что ответ от сервис лейера можно получить в том же запросе? А в саге только ридмодельку дёргать?
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Помоему мы обсуждаем одну из возможных реализаций саги, а не как концепт
источник

SB

Sergei Baikin in Software Design/Architecture/Zen
Sergey Protko
Cqrs сильно усложняет ui и вынуждает тебя довольно сложные вещи делать. Это оправдано там где без этого сложнее
если оно читает с той же базы которая для логики используется
то не вижу какого то особого услажнения с CQRS даже проще
Прикуртил RQL и запрашиваешь что надо без дополнительного кода (ну или вообще hasura/postgrestrest). Никаких ДТО порятнок и прочей дичи
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Dmitriy Tkachenko
Тоестт все отличие, что ответ от сервис лейера можно получить в том же запросе? А в саге только ридмодельку дёргать?
При этом нет гарантий когда твоя Рид моделька обновится.

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

SP

Sergey Protko in Software Design/Architecture/Zen
без этого твой CQRS тебе будет сюрпризы делать в духе "я выполнил операцию, пошел дальше а сервер еще не успел обработать и я вижу не то что ожидал"
источник

SP

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

SB

Sergei Baikin in Software Design/Architecture/Zen
Dmitriy Tkachenko
Тоестт все отличие, что ответ от сервис лейера можно получить в том же запросе? А в саге только ридмодельку дёргать?
Сага она ничего не дергает, она принимает и отправлет сообщения и это все что она делает для внешнего мира
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Dmitriy Tkachenko
Помоему мы обсуждаем одну из возможных реализаций саги, а не как концепт
сага это тупо штука которая слушает сообщения, которая сообщения принимает через очередь и обрабатывает сообщения одна сага одно сообщение за раз. Однопоточная штука такая. За счет этого разруливается конкурентность операций - у тебя сага - полноценный агрегат который гарантирует тебе что его стэйт всегда валиден

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

SP

Sergey Protko in Software Design/Architecture/Zen
либо у тебя будут "распределенные локи для работы саги" что убивает весь их смысл (смысл саг - избавиться от распределенных локов и позволить тебе делать распределенные транзакции надежно)
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Правильно я понимаю, что службы приложения по хорошему должны работать с одним репозиторием?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Segmentation Fault
Правильно я понимаю, что службы приложения по хорошему должны работать с одним репозиторием?
для них нет ограничений на количество и вид зависимостей.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
есть ограничение по наличию в них бизнес логики (принятие решений). Им можно задавать только очередность операций
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Sergey Protko
есть ограничение по наличию в них бизнес логики (принятие решений). Им можно задавать только очередность операций
То есть от других сервисов тоже может зависеть?
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Sergey Protko
без этого твой CQRS тебе будет сюрпризы делать в духе "я выполнил операцию, пошел дальше а сервер еще не успел обработать и я вижу не то что ожидал"
опять же, вопрос реализации. В JS с их нативным эвентлупом это вообще не проблема, если есть пуши
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Segmentation Fault
То есть от других сервисов тоже может зависеть?
конечно. Просто выглядеть код должен как-то типа...

DoMyVeryImportantUseCase(DoStuff command) {
   val firstThing = firstRepo.get(command.firstThingId)
   val secondThing = secondRepo.get(command.secondThingId)
   val fee = feeCalculation(command.amount)
   // ...
}
источник

SP

Sergey Protko in Software Design/Architecture/Zen
мол просто линейно дергаем разные штуки
источник