ну и важно - ивент сурсинг это частье когда у тебя есть пространство для эксперементов. Мол... вот челы у тебя заказывают штуки. Иметь карзину как ивент сурс агрегат оч выгодно потому что можно изучать как люди взаимодействуют с карзиной.

строить разные модели, предсказывать действия и т.д.

а вот те же заказы - ой сохрани стэйт и не еби мозги

просто храни логи ивентов отдельно

это интересно
потому что тут отдельность системы - это тонкий момент. 2 таблицы в бд - это тоже можно отдельными системами назвать
и таким макаром можно опять прийти к тому, что адаптер - с табличками может быть сагой 🤔
отдельные системы (таблицы в бд) есть
1 бизнес транзакция есть
если блокирование ресурсов неважно - можно гарантировать очерёдность и всё будет ок
да, мы не знаем результат и будет ли доступна табличка (а может её залочил кто)
компенсирующие действия опять же можно сделать
стейт есть (пока идёт выполнение)
может быть отличие в том, что в адаптере не должно быть иф-ов, а они будут, хоть и на уровне роллбека транзакций
то есть всё таки в адаптере можно захерачить сагу, но сага - это не адаптер

очень интересно, надо идти работать пока не забанили :D

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

это не тонкий момент. Это основной момент. отсутствие возможности гарантировать порядок и атормарность операций.

т.е. стейт меняется только в обработчике сообщения

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

Как следствие нам нужен кто-то третий который будет хранить стэйт системы (у кого че выполнилось) и следить за всеми, что бы чуть что можно было сказать "не откатывай" одной или другой системе.

вот этот третий - это сага. решение конкретной проблемы. Если у тебя этой проблемы нет но есть желание стэйт машину написать - то у тебя просто стэйт машина.

ибо так можно все сказать что "это стэйт машина". Останутся только всякие вероятносные структуры пожалуй которые не стэйт машина..

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

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

ну то есть из всего этого следует парочка оч серьезных ограничений. основное - саги не могут выполняться в контексте запроса

это всегда отдельный процесс всегда в бэкграунде

мне кажется сильно надумано

а иначе невыйдет гарантии все эти предоставить

иногда от фронтов слышно "ооой этот ваш CQRS, в жопу его! хочу получить изменения сразу же, не хочу ридмодельку дергать"

а чем контекст запроса мешает? Сага может и недолго жить по идее же
там дальше от ограничений бизнеса и железа зависит наверное 🤔

но CQRS это не про то что POST /users всегда void