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.
2 Comments
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”?
regards
Sławek Sobótka
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).