CQRS / ES with Rails

Mirosław Pragłowski / @mpraglowski

Storing a state

Storing events

Events

Something that has had already happened

Represents state change

Should be named in past tense

... and in business language (Ubiquitous Language)

They never change!

... unless you have a time machine

... or you play Orwell and rewrite history

CQRS

Did you mean CARS?

CQRS

Command and Query Responsibility Segregation

term coined by Greg Young (@gregyoung)

also Udi Dahan (@udidahan) involved

based on CQS devised by Bertrand Meyer

Bertrand defines CQS as: every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer.

Commands

Named in business language (Ubiquitous Language)

Express user's intention

Simple validations (regardless of context)

Rejection by exception or fault event

Can be asynchronous

a.k.a Form Object

Command Handlers

Handle commands :)

Entry point to your domain

Handle all plumbing

Cross cutting concerns as Chain Of Responsibility

Triggered by users, external systems or sagas (process managers)

a.k.a Service Object (some of them)

Aggregates

A place where (almost) all yours app logic should be

Set of objects holding consistent/valid state

Protecting invariants

... more in DDD books :)

Aggregates with CQRS/ES

State rebuild based on events

Source of new events

Do not expose state

Read Models

The model as your app needs it

Denormalized!

Tailor-made!

Recreatable!

Could be anything: relational DB, NoSQL store, graph database

... static HTML file ;)

a.k.a Query Objects (in half baked CQRS implementation with shared database)

CQRS app

CQRS app

Resources

Available at

http://praglowski.com/presentations/cqrses/

Sample code</h3>

https://github.com/mpraglowski/cqrses-sample/

</section>