The document discusses Command Query Responsibility Segregation (CQRS) and event-driven architecture. It defines CQRS as separating commands and queries, outlines its benefits like scalability and flexibility, and notes potential downsides like complexity. The document recommends applying CQRS for collaborative domains with parallel operations, and avoiding it for simple CRUD apps. It also discusses how event-driven architecture uses immutable states and loosely coupled applications, and how it pairs well with CQRS.
11. Globalcode – Open4education
so, why does it matter?
Scalability
Reduce complexity (domain level)
Flexibility
Focus on domain logic / proper technology
Task-based operations / Stale data
12. Globalcode – Open4education
but... and the downsides?
Learning curve / fear of change
Complexity
Eventual consistency
"Most people using CQRS (and event sourcing too) shouldn't have done so." —Udi Dahan
13. Globalcode – Open4education
so when should I apply it?
Decision per Bounded Context
Collaborative / complex domains
Multiple operations in parallel (stale data)
Distributed / specialized teams
Command vs Read performance
14. Globalcode – Open4education
and when avoid it?
Simple / static CRUD
Sequential operations
Non-collaborative bounded contexts
Eventual consistency not acceptable
16. Globalcode – Open4education
what’s that now?
State changes
Event consumers vs producers
Fire-and-forget
Happens in the past
“User created”, “User deleted”, ...
17. Globalcode – Open4education
and why is that good?
Immutable states
Loosely coupled apps
Fits well with some rock stars (CQRS and DDD)
Async process
State reproducibility
22. Globalcode – Open4education
lessons learned
Start small and extensible
Scale when you need to scale
Avoid huge / complex architectures for small problems
Avoid scaling when you don’t need to