Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Henrik Møller Rasmussen, profile picture
Uploaded byHenrik Møller Rasmussen
PDF, PPTX6,122 views

CQRS is not Event Sourcing

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.

Technology◦Business◦
Download as PDF, PPTX
CQRS != Event Sourcing
Henrik Møller Rasmussen Founder and CTO The digital daycare
The digital daycare 6 institutions! ~1.000 children
What is CQRS? Command Query Responsibility Segregation
CQRS WritingReading User
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
CQRS WritingReading User
What is Event Sourcing?
Classic approach to persistence Store snapshots
Event sourcing Store every thing that happens - chronologically.
 Build snapshots “on the fly.
EventStore Customer Example Customer new Customer(Kermit, Sesame Streeet 1) CustomerCreatedEvent(…)
EventStore Customer Example Customer $customer->move(Sesam Street 42) CustomerCreatedEvent(…) CustomerMovedEvent(…)
EventStore Customer Example Customer $customer->upgradeTo(Customer::PREMIUM) CustomerCreatedEvent(…) CustomerMovedEvent(…) CustomerUpgradedTo(…)
Rehydrating
Customer Example Customer { name: Kermit, address: Sesame Street 1, customerType: Customer::REGULAR } 2012-07-12T10:30:01! ! ! CustomerCreatedEvent(Kermit, Sesame Street 1)
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)
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)
What is CQRS + Event Sourcing? Reading User Writing Events
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
CQRS != Event Sourcing
Daily administration Check in/out Daycare homepage Parent App
LIVE DEMO FROM FAMLY.DK
Security Email Social …Daycare … … … Bounded Contexts from Famly
Children and their parents Checkin / Checkout / Pickup Vacation / Sickness Modules inside Daycare Context Institutions and groups Sleep Employees
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
REST API ChildCheckinService checkinChild(…) ChildViewService OKfindChildrenForGroup(…) CustomhandcraftedSQL Collection of DTOs
LIVE DEMO FROM FAMLY.DK
• 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
• 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
Daycare ChildDetails ParentDetails Vacation Security Email Social Only CQRS between modules
• 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
• 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
Henrik Møller Rasmussen! hmr@famly.dk 
 Twitter: @heinodk IRC: Come join us at #ddd The digital daycare