лучшеб ты цитировал как батя, пересказ не топ

Пролистываю Ваши сообщения.
И мне не совсем понятно, что означает "Не должны фейлится из за бизнес операций". А как же проверка бизнес правил и тд

ну сейчас бы на весь круд имейлы слать :)

Те все таки может зайфелится)

В этом и прикол - тебе не нужен cqrs там где нет колаборации

не, они не с фаулером спорили

это кто сказал ? Где написано ?

Сорян

У уди дахан

ну вот янг с ним не согласен, и што теперь ?

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

Скорее всего речь про это https://udidahan.com/2009/12/09/clarified-cqrs/

не согласен с тем, что cqrs это для того, чтобы двигаться от crud?

там вроде был смысл в том что можно скейлить ибо ты не предпологаешь о 100% консистентности апдейтов
да, вот и ссылка подехала

нет, вообще не согласен

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

> As we move away from a single representation that we interact with via CRUD, we can easily move to a task-based UI.

Like any pattern, CQRS is useful in some places, but not in others. Many systems do fit a CRUD mental model, and so should be done in that style. CQRS is a significant mental leap for all concerned, so shouldn't be tackled unless the benefit is worth the jump. While I have come across successful uses of CQRS, so far the majority of cases I've run into have not been so good, with CQRS seen as a significant force for getting a software system into serious difficulties.

У уди был пример системы бронирования билетов.