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
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
25. Children and their parents
Checkin / Checkout / Pickup Vacation / Sickness
Modules inside Daycare Context
Institutions and groups
Sleep
Employees
26.
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
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
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