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.


  1. slaweksobotka
    Posted September 9, 2012 at 1:10 pm | Permalink | Reply

    Imho: depends on semantics.
    W can consider different “levels” of Architecture (all are important):
    1. Application Architecture – now to structure code (responsibility) in one “module” of whole system.
    Application architectures ex:
    – layers (not tiers, different layers)
    – microcernel
    – ports&adapters (imho it’s unification of Layers + P&A + Pipes&Filters)
    – CqRS – hmmm can be used as separate Application Arch (or as inner structure of P&A “hexagon”)
    – … ?
    2. System Architecture – how to structure (encapsulate and integrate) “modules” in bigger “universe”
    You mentioned:
    – SOA
    – EDA (Pipes&Filters?)
    – …?
    3. Deployment, Security, Scalability,… Architectures

    According to this semantics ES is imho “just” a persistence technique.

    This is just my private “mental scaffolding” that helps to grasp and categorize ideas.
    What do You think about this approach to looking at different “zoom levels”?

    Sławek Sobótka

  2. Posted September 11, 2012 at 3:39 am | Permalink | Reply

    How about a single stand-alone system that does not integrate with other enterprise apps? Can we talk about architecture of such system or is it ‘just design’? If so, then SOA or EDA does not apply to it and being CQRS may be a one of the most important fact about this system’s design, right?

    Regarding these ‘systems of systems’ I agree that patterns are about internal structure (boxes) while styles are about communication (lines).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: