CQRS is not Event Sourcing

CQRS != Event Sourcing

Henrik Møller RasmussenFounder 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(…)

Cus

tom

han

dcra

fted

SQL

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