1. CQRS != Event Sourcing

2. Henrik Møller Rasmussen
Founder and CTO
The digital daycare

3. The digital daycare
6 institutions!
~1.000 children

4. What is CQRS?
Command Query Responsibility Segregation

5. CQRS
WritingReading
User

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. CQRS
WritingReading
User

8. What is Event Sourcing?

9. Classic approach to persistence
Store snapshots

10. Event sourcing
Store every thing that happens - chronologically.
Build snapshots “on the fly.

11. EventStore
Customer Example
Customer
new Customer(Kermit, Sesame Streeet 1)
CustomerCreatedEvent(…)

12. EventStore
Customer Example
Customer
$customer->move(Sesam Street 42)
CustomerCreatedEvent(…)
CustomerMovedEvent(…)

13. EventStore
Customer Example
Customer
$customer->upgradeTo(Customer::PREMIUM)
CustomerCreatedEvent(…)
CustomerMovedEvent(…)
CustomerUpgradedTo(…)

14. Rehydrating

15. Customer Example
Customer {
name: Kermit,
address: Sesame Street 1,
customerType: Customer::REGULAR
}
2012-07-12T10:30:01! ! ! CustomerCreatedEvent(Kermit, Sesame Street 1)

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. 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. What is CQRS + Event Sourcing?
Reading
User
Writing
Events

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. CQRS != Event Sourcing

21. Daily administration Check in/out
Daycare homepage Parent App

22. LIVE DEMO FROM FAMLY.DK

24. Security
Email
Social
…Daycare
…
…
…
Bounded Contexts from Famly

25. Children and their parents
Checkin / Checkout / Pickup Vacation / Sickness
Modules inside Daycare Context
Institutions and groups
Sleep
Employees

27. 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

28. REST API
ChildCheckinService
checkinChild(…)
ChildViewService
OKfindChildrenForGroup(…)
CustomhandcraftedSQL
Collection of DTOs

33. LIVE DEMO FROM FAMLY.DK

34. • 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

35. • 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

36. Daycare
ChildDetails ParentDetails
Vacation
Security
Email
Social
Only CQRS between modules

37. • 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

38. • 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

40. Henrik Møller Rasmussen!
hmr@famly.dk
Twitter: @heinodk
IRC: Come join us at #ddd
The digital daycare