я выделил)

"отправить письмо что не удалось зарезервировать билет" - это ж не совсем фэйл)

ну то есть процесс не остановится в неопределенном состоянии

что ты вкладываешь в фейл?

то что не позволяет тебе на уровне UI делать предположения что все хорошо и можно идти дальше по флоу)

а, тогда ушёл дальше в сумрак) мисандестендинг)

например флоу - заплати денежку и билетик твой. Операции типа холд денег и т.д. - это ж твои деньги - там нет конкаренси и т.д. и толку от CQRS там нет. Там можно подождать пока мы захолдим денежки. Ибо но мани но хани. А вот бронь можно уже сделать не дожидаясь подтверждения, потому что в 99% случаев все проходит хорошо а если что мы тебе деньги вернем. Главное не заставлять тебя ждать чего-то что бы ты не передумал покупать то говно которое тебе не нужно

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

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

во оно как, т.е. гарантия выполнения 100%

и даже не 99,99

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

потому и поинт основной - подход этот хорошо работает там где мы не хотим пользователей заставлять ждать и при этом не хотим проебывать их данные. Самый простой способ "заставить ждать и проебать данные" - это гонки (collaborative domain)

ну потому комманды и не возвращают ничего

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

благо юиды можно генерить и без персиста в базу

но просто надо понимать что CQRS это дорого и юзать этот подход просто так - это бернить деньги. А в кейсах аля "профиль пользователя обновить" это просто тупо оверинжениринг.

Ну а "шина команд" как обычно это делают - это просто command pattern. простой и удобный способ заставить разработчиков делать сервисы юзкейсы которые реально обслуживают только один юзкейс. Оно сильно древнее CQRS

(хотя в целом все что CQRS юзает было описано в 70-х, потому больше подход интересен)

еще комбинации этих подходов с event storming - тож прикольно только я так и не научился ивент сторминг этот делать нормально

все новое - хорошо забытое старое ))