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

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

Посмотри adsd - он там это шоворит

Ты ищешь оч простой ответ на сложный вопрос

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

если смотреть на техническую сторону, то это наоборот серьёзно усложняет реализацию систем

Масштабирование, простой пример - Рид реплики

рид реплика == цкрс ?

Или там оптимизированная под чтение моделька в рэдисе

Я тебе говорю зачем разделять

это надиктовано не цкрсом, а требованиями к системе

А cqrs не продиктован требованиями к системе?)

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

Опиши мне как у тебя cqrs выглядит? Ты его только для того что бы "хэндлеры хэндиди ток одну команду" юзаешь?

нормально делай, нормально будет!

это деталь реализации, мы здесь об архитектуре в целом говорим

собственно, дахан то же самое пишет

Ну для меня прям целый мир открылся с введением разделения на колаборатив и нон колаборатив домены

Что такое архитектура тогда?)

непонятно сказал

Это просто недопонимание в пересказе, уди пишет:
We could have a little widget on the side showing the user their pending commands, checking them off asynchronously as we receive confirmation from the server, or marking them with an X if they fail
что это значит?
1) команды не возвращают статус немедленно
2) мы подписываемся на статус команды который где-то хранится
3) когда статус обновляется мы пушим изменения вниз
так работают все современные штуки называемые стором во фронте, условный flux, redux, vuex и т.д и т.п.  на бэке очевидно мы держим сокеты для таких апдейтов, т.е. команды в полном смысле слова не возвращают ok/fail сами по себе