Papa Greg has returned from his walkabout to post a number of items about cqrs, architecture, event sourcing, and whatnot. If you find anything in my discussion of this stuff remotely interesting, you really should be reading his stuff first, since, although he didn’t exactly invent any of it (it’s all just things people have been doing before), he did name it and has done a lot of real-world work in making it a lot more sophisticated (not to mention presenting on it around the world), etc. etc. etc.
Anyhoo, in one of them, he emphasizes that cqrs, in and of itself, is not an architecture:
Many people have been getting confused over what CQRS is. They look at CQRS as being an architecture; it is not. CQRS is a very simple pattern that enables many opportunities for architecture that may otherwise not exist. CQRS is not eventual consistency, it is not eventing, it is not messaging, it is not having separated models for reading and writing, nor is it using event sourcing. I want to take a few paragraphs to describe first exactly what CQRS is and then how it relates to other patterns.
Since I’ve been talking about cqrs as it applies to architecture, I suppose a comment or two is in order.
First, it is correct that you cqrs is really just a way of writing code that, well, codifies CQS. In his current post, he talks about services, but cqrs doesn’t really require services either. You have separate objects/messages/commands/whatever for reads versus writes, you have cqrs.
But, more interestingly, I can just quote Greg from another recent post of his:
Udi put up a good post (and long) about Command and Query Responsibility Segregation. One point that Udi brought up is that people have tied together Event Sourcing and Command and Query Separation. They are certainly two different patterns…is CQRS itself better off by using Event Sourcing…The answer is a resounding yes…I hope this goes a way to explain why Event Sourcing and CQRS really go hand in hand.
I agree with this as well. While cqrs is not eventual consistency, eventing, messaging, etc. etc. etc., they all work together well.
So, keep in mind that this series should probably be named “cqrs-based architecture using messaging, eventing, and eventual consistency for dummies”, but marketing doesn’t like that.
In the next substantive post, I hope to talk about the command layer.