LOB apps

What are the main concerns?

LOB apps

What is important to Business?

Features

Quick changes

Maintainability

Cost

Performance

Pains?

CQRS & ES, it really is a ES & CQRS.

You can use CQRS without ES, but with ES you must use CQRS.

by Greg Young

Event sourcing

...but first

Eventual consistency

Consistency of data is a state which is eventually attained

...what leads us to CAP theorem

CAP theorem

Consistency all nodes see the same data at the same time
Availability a guarantee that every request receives a response about whether it succeeded or failed
Partition tolerance the system continues to operate despite arbitrary message loss or failure of part of the system

CAP theorem

...a distributed system cannot satisfy all three of these guarantees at the same time...

Eric Brewer

CAP theorem

Centralized system

we don't have network partitions (P)

... so it is CA system

Distributed system

we have network partitions (P)

... so it can be only CP or AP system

AP samples?

Amazon ;)

Tickets buying system

CP samples?

ATM application ;)

... but let's back to

Event sourcing

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

Storing events (revisited)

Pros of ES

Avoiding impedance mismatch (ORM)
Append only store - we never loose any data
Audit log for free
Complete rebuild, we could discard state and rebuild it by re-running events
Events can be replayed if there is a need to re-process old data
Easy to do temporal queries
Easy to implement different read models
Performance improvement (easier to scale)

Cons of ES

You could not change anything in database
... but hey, that's I would count as pros :)
It takes a while to change your mindset
Need of separate models for reporting
... but hey, that's not really a bad thing!
Lack of tooling

Typical RoR app

Complex RoR app

Separating reads from writes

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)

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

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

Pros of CQRS

Performance
... we could have database optimized for reads
... and we could scale reading independently of writing
Simplicity & ease of changes in read side
Decluttering domain (moving reads to read model)
Easier to test

Cons of CQRS

Still pretty new and not familiar to devs
... and requires mindset change
Requires more infrastructure
Must remember about eventual consistency
... but hey, we deal with this every day

CQRS / ES with Rails