4. What is CQRS?
Separating Reads from Writes
Command
Query
Responsibility
Segregation
An architectural pattern that separates
Commands, that change state, from Queries that
only read state.
5. Simple Example of CQRS
Segregating Queries
Presentation
Validation Queries (generate DTOs)
Commands
Domain Logic
Data persistence
Based on Rob Ashton’s
codeofrob.com/entries/cqrs-is-too-complicated.html
6. Taking it further…
Separate Data Stores
Presentation
Validation Queries (generate DTOs)
Commands
Domain Logic
Data persistence
7. What is Event Sourcing?
An Alternate Way to Represent the Data
Relational Model
Event Stream
Shipping
Item 1
Cart Created Item 1 Added Item 2 Added Information
Removed
Added
8. CQRS / ES
Presentation
Validation Read thin-layer
Commands
Domain Logic
Data persistence
Based on Rob Ashton’s
codeofrob.com/entries/cqrs-is-too-complicated.html
9. Eventual Consistency
The Trade-Off
• Asynchronous is faster, but may yield stale data
• Write Model can be consistent
• Write Model is the source of truth
16. When to Use CQRS?
• Do multiple users compete for access to the same resources?
• Are the business rules ever changing?
• Is scalability one of the challenges?
• Is the business logic complex?
• Are benefits that CQRS brings clear?
17. Benefits
CQRS & Event Sourcing
• Integration with other systems / screens
• Versioning / Evolution
• Team development
• Testing
• Performance can be fine-tuned separately
18. Some Lessons Learned
• Throw away your assumptions
• CQRS space is a little confusing - inconsistency, dissonance
• Not a top-level architecture
• Not everything needs to be asynchronous, nor message-based
• In messaging, tracing matters big time
• Test for performance early
• Find or build a robust infrastructure that fits your needs
• “Sagas” != sagas; Avoid them at first
A very popular topic in the developer community.But also an area where there was lots of confusion.This was a different kind of project for p&p.Not about Prescriptive Guidance,More of a Journal of Our Experiences, a Case Study
Similar to CQS, but applied to a BC/Subsystem as opposed to Objects.
If you are using an ORM, such as Entity Framework or Nhibernate, then you would have two different models: write and read.There would be no need for lazy loading.
Now that you have different models, you can go to the next step and have separate data stores.Not required for CQRS.This could be replication, transformation, projection, etc.This is good for scalability. Because READS tend to outnumber WRITES.Queries can be expensive, we want to make them cheaper.
ES contains a lot more information.Tries to preserve events that make sense in the business (with its intent)To get the current status, you can get the event stream and replay.Not very easy to query other than by ID.
From Nicomachean Ethics
We were exploring the landscape.Report our findings.Not a Framework, not a LibraryThe idea is to go through building a non-trivial system that uses CQRS and event sourcing and report back on the lessons learnt.
Conference Management – setting up a conferenceOrders & Registration – for reserving and purchasing ticketsPayments – for interacting with external payment providerDiscounts – not implemented (et al)
Infrastructure: needs to scale out? Messaging. code evolution No downtime migrationsIf messaging: follow best practices for scalability.