You are on page 1of 24

History Defines Us...

Event Sourcing in practice

Adam Kosiński, 4Developers 2013

About what is Event Sourcing?
Imagine a bank account:
Transaction

Amount

Balance after transaction

Payment Deposit

+ $3000

$3000

Bill Payments

- $1800

$1200

CC Charge

- $900

$300

Speed Fine

- $300

$0

Retrieving our data:
Save state approach

WTF!?
Why no money?

$0

Event sourcing
Payment Deposit

+ $3000

Bill Payments

- $1800

CC Charge

- $900

Speed Fine

- $300

Hmm… need
cheaper room

$0

Seriously, what is ES?
Entity (State 0)

Domain Event #1

Entity (State 1)

Entity (State 1)
Domain Event #1
Domain Event #2

...
Domain Event #n
Entity (State n)

We only need events
Domain Event #1
Domain Event #2
Domain Event #3

...
Domain Event #4
Domain Event #5
Domain Event #6
Entity (Version 6)
Persisted!

What is Domain Event

Something important

Something foreseen in domain model

Something happened in the past

Sample Domain:
Room Access Control
Access Control Zone

AC Software

Hardware
Controlers

Valid Permission

Lock
None or invalid Permission

Access Control Model

Demo #0
Initial, save state model

Demo #1
What We need for Event Sourcing:

Domain Events

Event Store

Event handling methods

What can be used as event store:

SQL Relational DB (slight overkill)

NoSql (ie. RavenDB)

EventStore by Greg Young

Even simple file storage :)

Event Sourcing pros:

No ambiguity between events and data model

Complete historical data

No DB maintenance when modyfying

Very fast data update

Event Sourcing
Limitations

Performance when events grow

Can be troublesome to replay incerasing
number of events every time
Solution:
Serialized, captured state of entity - Snapshot

Snapshot
Event #1
Event #2
Event #3
Event #4

Snapshot (Version3)

Event #5

Event #4

Event #6

Event #5
Event #6

Entity (Version 6)

Demo #2

Creating and restoring snapshots

Snapshot store

Yet another issue - Queries

How should we filter queries?
select * from eventStore.Entities where … (? ? ?)

Almost always a good idea: CQRS

What's with
Command-Query Responsibility Segregation ?
Query
(non-domain views)

Read Side

view-only data

User

UI

Command
(non-domain parameters)

Lift up domain entities

DB

Update domain Entities

Domain Logic

Why CQRS helps ES

Query
(non-domain views)

Read Side

view-only data

Read
Store

User

UI

Command
(non-domain parameters)

Synchronization

Event
Store

Domain Logic
Add Events

Demo #3

How does Read Store look like

Synchronization – Read Side Update

ES – to do or not to do

Yes when:

Event Driven
Architecture

Maybe no when:

Simple CRUD apps

No events needed

History data need

Initial cost too high

Concurency

Legacy software

Scalable, modifiable
systems

What next:

Greg Young blog, Event Store website:

Udi Dahan

http://www.udidahan.com/

Project CQRS Journey

http://geteventstore.com/blog/

http://cqrsjourney.github.io/

Szymon Pobiega

http://simon-says-architecture.com/

Thanks for watching!

meet me at:
https://twitter.com/a_kosinski