Is CQRS an Architecture?

I got involved in an interesting discussion with Vaughn Vernon and Ashic Mahtab on twitter today over whether or not CQRS was an architecture. Why do some people see it as such and others not? The answer, I think we all agree, is one of context. The principle behind CQRS is merely one of separation, that of commands from queries. Here’s a couple of examples. Suppose you have a service that consists of methods that perform work (commands) and methods that return data (queries). You may decide to split it into two separate services, one with all the commands on it and the other with all the queries. The implementation behind this separation is not important. It is the act of separation itself that gives rise to interesting possibilities because now your two services can evolve independently. You could do this of course inside of an existing, already well-established architecture, even the classic big ball of mud architecture. That wouldn’t mean you now had a CQRS architecture though. On the other hand, if you we’re designing a new system from scratch and happened to identify a particular bounded context in which CQRS would add value then at this point you would be making an architecturally significant decision because the whole chosen architectural style has certain implications for how the system will evolve over time and the required skill level of the team writing it.

Both approaches result in applying the principle of separating reads from writes but are very different in implementation and importance. The truth is that CQRS is an overloaded term hence why it seems to cause so much confusion to developers looking at it for the first time. You have to consider the context in which you are applying the principle. Is it at the class level? At the bounded context level in DDD terms, or in some other context?

Is CQRS an architecture? In general, most agree that it’s not one that you would choose to apply across the entire system. At its largest, a particular bounded context would probably be the norm. It may well be architecturally significant to the context in which you are applying it but that doesn’t mean you’d use it everywhere. On the other hand, deciding to split one class into two probably has little architectural significance but you’ve still applied the principle. I think it’s important to keep banging the drum on this separation idea to stress to anybody looking at it for the first time that the principle behind CQRS is not that complicated. The main thing to remember is that, just as with any other decision, context is king and some contexts can have potentially far reaching implications.