Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Event Sourcing in practice

Event Sourcing in practice

Adam Kosiński

April 12, 2013
Tweet

Other Decks in Programming

Transcript

  1. 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
  2. Save state approach $0 WTF!? Why no money? Event sourcing

    Payment Deposit + $3000 Bill Payments - $1800 CC Charge - $900 Speed Fine - $300 $0 Hmm… need cheaper room Retrieving our data:
  3. Domain Event #1 ... Domain Event #2 Domain Event #3

    Domain Event #4 Domain Event #5 Domain Event #6 Entity (Version 6) We only need events Persisted!
  4. What is Domain Event • Something important • Something foreseen

    in domain model • Something happened in the past
  5. Sample Domain: Room Access Control AC Software Hardware Controlers Access

    Control Zone Lock Valid Permission None or invalid Permission
  6. Demo #1 What We need for Event Sourcing: • Domain

    Events • Event Store • Event handling methods
  7. What can be used as event store: • SQL Relational

    DB (slight overkill) • NoSql (ie. RavenDB) • EventStore by Greg Young • Even simple file storage :)
  8. Event Sourcing pros: • No ambiguity between events and data

    model • Complete historical data • No DB maintenance when modyfying • Very fast data update
  9. Performance when events grow • Can be troublesome to replay

    incerasing number of events every time • Solution: Serialized, captured state of entity - Snapshot
  10. Snapshot Event #1 Snapshot (Version3) Entity (Version 6) Event #2

    Event #3 Event #4 Event #5 Event #6 Event #4 Event #5 Event #6
  11. Yet another issue - Queries • How should we filter

    queries? • Almost always a good idea: CQRS select * from eventStore.Entities where … (? ? ?)
  12. What's with Command-Query Responsibility Segregation ? User UI DB Query

    (non-domain views) Domain Logic Read Side view-only data Lift up domain entities Update domain Entities Command (non-domain parameters)
  13. Why CQRS helps ES User UI Read Store Query (non-domain

    views) Domain Logic Read Side view-only data Add Events Command (non-domain parameters) Event Store Synchronization
  14. Demo #3 • How does Read Store look like •

    Synchronization – Read Side Update
  15. ES – to do or not to do • Yes

    when: – Event Driven Architecture – History data need – Concurency – Scalable, modifiable systems • Maybe no when: – Simple CRUD apps – No events needed – Initial cost too high – Legacy software
  16. What next: • Greg Young blog, Event Store website: –

    http://geteventstore.com/blog/ • Udi Dahan – http://www.udidahan.com/ • Project CQRS Journey – http://cqrsjourney.github.io/ • Szymon Pobiega – http://simon-says-architecture.com/