вот там где высока вероятность конфликта действий человеков - там CQRS представляет ценность. Не как техническая штука, а как способ моделировать и дробить операции. Мол "команда не должна фэйлиться" (по бизнес причинам, не потому что там база упала и т.д.). И с этим ограничением ты уже думаешь как это все организовать.
взад назад ты шлёшь некие данные, допустим, для апдейта элемента или ещё хуже, для патча принимаешь, обрабатываешь и сохраняешь никакого иного ui, чем уже есть, скорее всего не надо
Мы отредактировали описание товара. Почему? Потому что нам нужно действительно новое описание чтобы лучше продавать или менеджер просто пропустил запятую? В Task Based UI главное это Task. Если теряется контекст (и это не всегда причина редактирования, кто или когда), то такое дробление приведет только к усложнению API.
Все эти идеи очень плохо ложаться на CRUD модельки (хотя и их можно представить как ES, и на этапе прототипирования так можно делать чтобы не усложнять инфраструктурный слой)