Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. CQRS&Event sourcingEvent sourcingEvent sourcing
  2. 2. About me• Lifetime hacker• Explorer of technologies• Polyglot programmer• @sorenmat• https://github.com/sorenmat
  3. 3. CQRS + ES• What is CQRS• What is Event sourcing• Demo
  4. 4. Typical N-TIER architecturepros• Well known• Accepted bymanagement• Lots of resources• Lots of frameworks
  5. 5. Typical N-TIER architecturecons• Complex• Business logic bleeds throughlayers• Validation everywhere• No provable audit trail• No concept of change• Caching• Hard to scaleNo concept of change -> classchange customer state meanswhat ever hibernate saysNo concept of change -> classchange customer state meanswhat ever hibernate says
  6. 6. CQRS to the rescueCQRSWTF!!
  7. 7. CQRS to the resuceCommandQueryResponsibilitySegregationWTF!!
  8. 8. CQRSBased upon Bertrand Meyer’s CommandQuery Separation (CQS) principle:“every method should either be a command thatperforms an action, or a query that returns data tothe caller, but not both. In other words, asking aquestion should not change the answer” (Meyer)
  9. 9. Why CQRS ?• Scalability• Reduced complexity• Flexibility• Focus on the businessMaking commands, gives focus onthe businessMaking commands, gives focus onthe business
  10. 10. 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
  11. 11. CQRS Structure
  12. 12. Commands• Commands ask thesystem to do changes• Commands can fail• State intent• Can be asynchronous
  13. 13. Stale data• Async - ooohh nooes• Eventual consistency• How stale must stale data be ?• How stale is your data ?• Design for it
  14. 14. Read Models• Build for the “UI”• Optimized for theuse case• Comes in all shapeand forms
  15. 15. Event sourcing
  16. 16. Don’t save the result, save the steps !
  17. 17. 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
  18. 18. Aggregates•A boundary for transactional consistency•Only one aggregate can be modified in a singletransaction•A cloud of related objects, both entities andvalue objects•Only the root can be referenced from outside theaggregate
  19. 19. Aggregates•Must ensure that its state never ever violates itsbusiness invariants•Between the boundaries, there can only beeventual consistency
  20. 20. Aggregate example• Aggregate are the “base” of the model• Order is the aggregate root• Order has an addLineItem method
  21. 21. Event stream•Every state-modifying operation on anaggregate results in an event•The actual state change is achieved by applyingthe event to the aggregateOrderCreatedOrderCreated OrderLineItemAddedOrderLineItemAdded OrderLineItemRemovedOrderLineItemRemoved OrderLineItemAddedOrderLineItemAdded
  22. 22. Events• Represents the state of the aggregate• Passed tense, can’t be undone• Events never changes
  23. 23. Event sourcing• Conflict merging• Easy integration• Expose events through feed• Very testable
  24. 24. Event store• Stores all events• Append only• Single source of truth
  25. 25. Event store• Simple in design• Few operations• append• getAllEvents• getEventsForAggregate
  26. 26. Event Store• Performance can be gained throughsnapshots• Serialize the aggregate with an eventId
  27. 27. Summary
  28. 28. Pros and Cons• Great performance• Very scalable• Auditing• Easy to integrate• Testable• Tech free• Not well known• Different mindset
  29. 29. DEMO
  30. 30. Our model