Download to read offline
Uploaded bySøren Mathiasen
Cqrs+es
This document discusses CQRS (Command Query Responsibility Segregation) and event sourcing architectures. It begins by introducing the speaker and providing an overview of CQRS and event sourcing. It then contrasts typical N-tier architectures with some limitations around complexity, validation, and auditing. CQRS is presented as a solution to address these limitations by separating reads from writes and using an event sourcing approach. Key aspects of CQRS are explained, including commands, queries, read models, events, aggregates, and event stores. Pros and cons are listed, and then a demo is promised to illustrate the concepts discussed.
![[BDD 2025 - Full-Stack Development] Agentic AI Architecture: Redefining Syste...](https://cdn.slidesharecdn.com/ss_thumbnails/fs-agenticaiarchitectureredefiningsystemcommunication-251124030838-e6c70cc2-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Full-Stack Development] The Modern Stack: Building Web & AI Appli...](https://cdn.slidesharecdn.com/ss_thumbnails/fs-themodernstackbuildingwebaiapplicationswithserverless-251124030844-388cf04f-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Full-Stack Development] PHP in AI Age: The Laravel Way. (Rizqy Hi...](https://cdn.slidesharecdn.com/ss_thumbnails/fs-phpinaiagethelaravelway-251125012602-ef9d330e-thumbnail.jpg?width=640&height=640&fit=bounds)
Cqrs+es
- 1.
- 2. About me • Lifetimehacker • Explorer of technologies • Polyglot programmer • @sorenmat • https://github.com/sorenmat
- 3. CQRS + ES •What is CQRS • What is Event sourcing • Demo
- 4. Typical N-TIER architecture pros •Well known • Accepted by management • Lots of resources • Lots of frameworks
- 5. Typical N-TIER architecture cons •Complex • Business logic bleeds through layers • Validation everywhere • No provable audit trail • No concept of change • Caching • Hard to scale No concept of change -> class change customer state means what ever hibernate says No concept of change -> class change customer state means what ever hibernate says
- 7. CQRS to therescue CQRS W TF !!
- 8. CQRS to theresuce Command Query Responsibility Segregation W TF !!
- 9. CQRS Based upon BertrandMeyer’s Command Query Separation (CQS) principle: “every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer” (Meyer)
- 10. Why CQRS ? •Scalability • Reduced complexity • Flexibility • Focus on the business Making commands, gives focus on the business Making commands, gives focus on the business
- 11. CQRS in themaking • Let’s focus on the language - AddItemToBasket vs UpdateBasket • Task based UI • We need to separate reads from writes • Lets split our architecture
- 12.
- 13. Commands • Commands askthe system to do changes • Commands can fail • State intent • Can be asynchronous
- 14. Stale data • Async- ooohh nooes • Eventual consistency • How stale must stale data be ? • How stale is your data ? • Design for it
- 15. Read Models • Buildfor the “UI” • Optimized for the use case • Comes in all shape and forms
- 16.
- 17. Don’t save theresult, save the steps !
- 18. Event sourcing •Analysis andaccess to historic data •Provable Audit log •Flexibility to create new views or queries (CQRS) •Replaying events for debugging •Enables Memory Image
- 19. Aggregates •A boundary fortransactional consistency •Only one aggregate can be modified in a single transaction •A cloud of related objects, both entities and value objects •Only the root can be referenced from outside the aggregate
- 20. Aggregates •Must ensure thatits state never ever violates its business invariants •Between the boundaries, there can only be eventual consistency
- 21. Aggregate example • Aggregateare the “base” of the model • Order is the aggregate root • Order has an addLineItem method
- 22. Event stream •Every state-modifyingoperation on an aggregate results in an event •The actual state change is achieved by applying the event to the aggregate OrderCreatedOrderCreated OrderLineItemAddedOrderLineItemAdded OrderLineItemRemovedOrderLineItemRemoved OrderLineItemAddedOrderLineItemAdded
- 23. Events • Represents thestate of the aggregate • Passed tense, can’t be undone • Events never changes
- 24. Event sourcing • Conflictmerging • Easy integration • Expose events through feed • Very testable
- 25. Event store • Storesall events • Append only • Single source of truth
- 26. Event store • Simplein design • Few operations • append • getAllEvents • getEventsForAggregate
- 27. Event Store • Performancecan be gained through snapshots • Serialize the aggregate with an eventId
- 28.
- 29. Pros and Cons •Great performance • Very scalable • Auditing • Easy to integrate • Testable • Tech free • Not well known • Different mindset
- 30.
- 31.