Cqrs+es
Download as PPT, PDF0 likes196 views
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.
Cqrs+es
- 1. CQRS & Event sourcing Event sourcing Event sourcing
- 2. About me • Lifetime hacker • 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 the rescue CQRS W TF !!
- 8. CQRS to the resuce Command Query Responsibility Segregation W TF !!
- 9. CQRS Based upon Bertrand Meyer’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 the making • Let’s focus on the language - AddItemToBasket vs UpdateBasket • Task based UI • We need to separate reads from writes • Lets split our architecture
- 12. CQRS Structure
- 13. Commands • Commands ask the 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 • Build for the “UI” • Optimized for the use case • Comes in all shape and forms
- 16. Event sourcing
- 17. Don’t save the result, save the steps !
- 18. Event sourcing •Analysis and access 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 for transactional 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 that its state never ever violates its business invariants •Between the boundaries, there can only be eventual consistency
- 21. Aggregate example • Aggregate are the “base” of the model • Order is the aggregate root • Order has an addLineItem method
- 22. Event stream •Every state-modifying operation 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 the state of the aggregate • Passed tense, can’t be undone • Events never changes
- 24. Event sourcing • Conflict merging • Easy integration • Expose events through feed • Very testable
- 25. Event store • Stores all events • Append only • Single source of truth
- 26. Event store • Simple in design • Few operations • append • getAllEvents • getEventsForAggregate
- 27. Event Store • Performance can be gained through snapshots • Serialize the aggregate with an eventId
- 28. Summary
- 29. Pros and Cons • Great performance • Very scalable • Auditing • Easy to integrate • Testable • Tech free • Not well known • Different mindset
- 30. DEMO
- 31. Our model