Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CQRS is not Event Sourcing


Published on

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

CQRS is not Event Sourcing

  1. 1. CQRS != Event Sourcing
  2. 2. Henrik Møller Rasmussen Founder and CTO The digital daycare
  3. 3. The digital daycare 6 institutions! ~1.000 children
  4. 4. What is CQRS? Command Query Responsibility Segregation
  5. 5. CQRS WritingReading User
  6. 6. What is important (for most systems) Reading! • Support a lot of concurrent reads • Fast as possible • Combine, aggregate, calculate • Create new views / reports without risk of introducing bugs in existing code • Scale reading independently of writing Writing! • Fewer writes than reads • Performance not that important
 (< 1s probably ok) • Simple models that are easy to understand and reason about • Easy to test
  7. 7. CQRS WritingReading User
  8. 8. What is Event Sourcing?
  9. 9. Classic approach to persistence Store snapshots
  10. 10. Event sourcing Store every thing that happens - chronologically.
 Build snapshots “on the fly.
  11. 11. EventStore Customer Example Customer new Customer(Kermit, Sesame Streeet 1) CustomerCreatedEvent(…)
  12. 12. EventStore Customer Example Customer $customer->move(Sesam Street 42) CustomerCreatedEvent(…) CustomerMovedEvent(…)
  13. 13. EventStore Customer Example Customer $customer->upgradeTo(Customer::PREMIUM) CustomerCreatedEvent(…) CustomerMovedEvent(…) CustomerUpgradedTo(…)
  14. 14. Rehydrating
  15. 15. Customer Example Customer { name: Kermit, address: Sesame Street 1, customerType: Customer::REGULAR } 2012-07-12T10:30:01! ! ! CustomerCreatedEvent(Kermit, Sesame Street 1)
  16. 16. Customer { name: Kermit, address: Sesame Street 42, customerType: Customer::REGULAR } 2013-10-24T08:16:37! ! ! CustomerMovedEvent(Sesame Street 42) Customer Example 2012-07-12T10:30:01! ! ! CustomerCreatedEvent(Kermit, Sesame Street 1)
  17. 17. 2014-01-05T14:52:04! ! ! CustomerUpgradedTo(Customer::PREMIUM) Customer { name: Kermit, address: Sesame Street 42, customerType: Customer::PREMIUM } Customer Example 2012-07-12T10:30:01! ! ! CustomerCreatedEvent(Kermit, Sesame Street 1) 2013-10-24T08:16:37! ! ! CustomerMovedEvent(Sesame Street 42)
  18. 18. What is CQRS + Event Sourcing? Reading User Writing Events
  19. 19. CQRS is no silver bullet • Requires a lot of infrastructure • Not able to edit anything directly in the DB
 (of course we never do that :-) • Pretty complex - hard to explain to junior developers
  20. 20. CQRS != Event Sourcing
  21. 21. Daily administration Check in/out Daycare homepage Parent App
  23. 23. Security Email Social …Daycare … … … Bounded Contexts from Famly
  24. 24. Children and their parents Checkin / Checkout / Pickup Vacation / Sickness Modules inside Daycare Context Institutions and groups Sleep Employees
  25. 25. REST API Famly Admin Famly App Famly Checkin Famly Homepage Writing (Commands)Reading (Query) Feed … and more Daycare MySQL DB Feed … and more Daycare Famly Architecture
  26. 26. REST API ChildCheckinService checkinChild(…) ChildViewService OKfindChildrenForGroup(…) CustomhandcraftedSQL Collection of DTOs
  28. 28. • Simpler and smaller write-models, that are easy to reason about, because they don’t need any view-logic. (getters etc.)
 • High-performing reads, since you fully utilize your underlying database server, and don’t need ORM’s for reading.
 • Extreme flexibility since the only things needed to build new view-models are SQL Benefits of using CQRS this way
  29. 29. • You couple the modules through their underlying persistence structure! ! • The handwritten SQL is expecting certain columns names etc. So changing the write models will potentially break read models.
 • So, have strict rules for where you are allowed to use this WARNING
  30. 30. Daycare ChildDetails ParentDetails Vacation Security Email Social Only CQRS between modules
  31. 31. • If you have views that combines information for a lot of different subsystems
 • If you have complex data structures that can benefit from doing data manipulation directly in the database (joins, subselect, counts etc. When to use
  32. 32. • Even though the app communicates with a lot of underlying subsystems, it only fetches data for a single child, and performance therefore is not a problem. CQRS not needed for the app
  33. 33. Henrik Møller Rasmussen! 
 Twitter: @heinodk IRC: Come join us at #ddd The digital daycare