CQRS is not a silver bullet
CQRS is not a top level architecture
CQRS is not new
CQRS is not shiny
CQRS will not make your jump shot any better
CQRS is not intrinsically linked to DDD
CQRS is not Event Sourcing
CQRS does not require a message bus
CQRS is not a guiding principle / CQS is
CQRS is not a good wife
CQRS is learnable in 5 minutes
CQRS is a small tactical pattern
CQRS can open many doors.
And yes you can support RFC 2549 using CQRS
6 Comments
I can’t prove causation, but my jump shot is totally improving.
Give me the 10 sentence, 5 minute rub on the essence of the small tactical pattern and this post is helpful.
Bing is your friend
Neither Bing nor Google gives me something as compact as “CQRS is a simple pattern that strictly segregates the responsibility of handling command input into an autonomous system from the responsibility of handling side-effect-free query/read access on the same system. Consequently, the decoupling allows for any number of homogeneous or heterogeneous query/read modules to be paired with a command processor and this principle presents a very suitable foundation for event sourcing, eventual-consistency state replication/fan-out and, thus, high-scale read access. In simple terms: You don’t service queries via the same module of a service that you process commands through. For REST heads: GET wires to a different thing from what PUT/POST/DELETE wire up to.”
Alright. I hereby declare my previous comment the Greg-endorsed CQRS definition