я не верю в то, что сейчас вкладывают в саббатикал

в изначальный смысл - верю

Всем привет, помогите с пониманием.
согласно принципу cqrs команда ничего не должна возвращать.

получается если при запросе мне надо сначала получить данные (query), потом эти данные изменить (command), а затем вернуть результат в виде новой модели (query), чтобы на фронте отобразить изменения, мне надо в контроллере выполнить три действия (запрос, сохранения, запрос)?
или я что-то не тек понимаю в этом паттерне.

По моему, вы не так понимаете этот принцип

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

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

Что я понимаю не так, или как это сделать правильно?

Ну никто не запрещает оптимистичное обновление

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

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

Мне видется это так
Отправляем запрос на "утверждение",
Пользователю показываете какой то сигнал что идет обновление, спинер уже не тренд, но что то в этом роде
Когда приходет статус ОК, делаете запрос на обновление данных документа
Данные приходят, "спинер" отключаем и показываем что данные по документу обновились
При ошибке на любом из этапов показываем это пользователю

Можно сделать оптимистичное обновление полей, которые точно известны, остальные временно задизаблить или показать на их месте скелетон

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

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

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

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

Из разных бд можно и без cqrs читать и писать

Возможно вам подойдет обновление по сокету

без доп запросов

я так и делаю сейчас, просто хотелось бы понять подход cqrs.
Спасибо за ответы.

По мне, так эта архитектура больше подходит для бэка и тащить ее на фронт я бы не стал. Но с ней нужно как-то считаться при работе сданными на фронте

Обновление по сокету или лонгполлинг, мне кажется, приемлемое решение