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.
Exploring CQRS and Event Sourcing
Exploring CQRS and Event SourcingA journey into high scalability, availability, and maintainability with Windows Azure
What is CQRS?Separating Reads from WritesCommandQueryResponsibilitySegregation An architectural pattern that separates Commands, that change state, from Queries that only read state.
Simple Example of CQRSSegregating Queries Presentation Validation Queries (generate DTOs) Commands Domain Logic Data persistence Based on Rob Ashton’s codeofrob.com/entries/cqrs-is-too-complicated.html
Taking it further…Separate Data Stores Presentation Validation Queries (generate DTOs) Commands Domain Logic Data persistence
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
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
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
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?
BenefitsCQRS & Event Sourcing• Integration with other systems / screens• Versioning / Evolution• Team development• Testing• Performance can be fine-tuned separately
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