CQRS is not an Architecture

CQRS is not an Architecture:
Just a quick posting from some conversations that were going around. CQRS is not an architecture.
CQRS can be called an architectural pattern. Just like Transaction Script is an architectural pattern. Event Sourcing is also an architectural pattern (it is also not an architecture or an architectural style).
CQRS and Event Sourcing are not architectural styles. Service Oriented Architecture, Event Driven Architecture are examples of architectural styles. They describe a system of systems (or a system of many components depending on how you express things). CQRS and Event Sourcing describe something inside a single system or component.
This is very important to understand most architectural patterns are not good to apply everywhere. If you see architectural patterns in an architectural guideline you probably have a problem (if you see an architectural style in a guideline its much safer). EG: To say “all components must use active record” = bad. To say “integration between components must be async and done through events” = no so bad. The largest failure I see from people using event sourcing is that they try to use it everywhere.
There is only one architecture. It is the one of the system you are talking about. It is its own set of trade offs and decisions that have been made. It is how it works.
When we talk about your architecture you could have SOA+EDA with ActiveRecord+CRUD in some places and Event Sourcing in others. Your system is unique, you system has its own architecture.

DIGITAL JUICE