CQRS and event sourcing are separate concepts that are often confused. CQRS (Command Query Responsibility Segregation) separates read and write operations, while event sourcing stores all state changes as a sequence of events. The document discusses CQRS, event sourcing, and how the digital daycare system uses CQRS but not event sourcing by having separate write and read models with custom SQL queries to retrieve data from multiple bounded contexts for the parent app.
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