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

Introduction to Event Sourcing ...and cqrs

Introduction to Event Sourcing ...and cqrs

Event sourcing is a pattern for modeling the application’s business logic. It states that all changes to application state should be defined and stored as a sequence of events. Its advantages are many:

Gives freedom to refactor the business logic, allowing better response to new requirements.
Suitable for building scalable, highly concurrent, distributed systems.
Stored events give the true history of a system, which is required by law in some industries.
The system’s state can be reversed to any point in the past for retroactive debugging.
The required infrastructure is simple – no monstrous databases are involved.
Vladik will also describe CQRS, an architecture that goes hand in hand with Event Sourcing.

Vladik Khononov

July 29, 2015
Tweet

More Decks by Vladik Khononov

Other Decks in Programming

Transcript

  1. – www.dictionary.com Model: A simplified representation of a system or

    phenomenon. – www.wikipedia.org לדומ: גוציי יטרואת לש תכרעמ תבכרומ , ותרטמש תוקחל תא תכרעמה םיטביהב םייתוהמ . לדומה וניא ראתמ לכ העפות תכרעמב , אלא סחייתמ םיטביהל םירדגומ םימצמוצמו הלש . לדומה ססובמ לע בוריק לש תואיצמה ךרדב לש הטשפה , דוחיא תויושי תומלעתהו םימרוגמ םתעפשהש הניא תיתוהמ .
  2. Good Domain Model • Not too much • Not too

    less • Sweet spot • The information we need • The information we will need
  3. Why domain models fail • We absolutely suck at predicting

    the future • No single model can suit all the use cases • Model transformations are painful
  4. • A customer has customer id number and a name

    • A customer has contact information: email, phone number • A customer can be in on of the following states: New, CallLater, Converted, NotInterested • A seller has seller id number, name and password • The selling home page contains a list of the customers in the following statuses: • New • CallLater (when scheduled call date is met)
  5. • Seller chooses a customer to call from the home

    page • Seller can change the customer’s status to “Converted”, “Not Interested” • Seller can schedule a future call by setting the future call date. The Customer’s status will change to “CallLater” • Seller can change name, email, and phone number
  6. enum Status { New, CallLater, Converted, NotInterested } class Customer

    { int Id; string Name; Status Status; DateTime? ScheduledCall; string Email; string PhoneNumber; } CREATE TABLE Customers ( ID INTEGER, Name CHAR(40), Email CHAR(40), PhoneNumber CHAR(40), Status INTEGER, ScheduledCall DATETIME, PRIMARY KEY (ID) ) class Seller { int Id; string Name; string Password; } CREATE TABLE Sellers ( ID INTEGER, Name CHAR(40), Password CHAR(40) PRIMARY KEY (ID) )
  7. • Seller can find customers by name, email, and/or phone

    number in the search page • The customers should be found by the current and the past values
  8. • If no new customers are available on the home

    page, it should display customers in the NotInterested status, if it was set more than a 30 days ago
  9. • Analysts should be able to review status changes history

    for each customer - change date and the new status
  10. class Seller { int Id; string Name; string Password; }

    CREATE TABLE Sellers ( ID INTEGER, Name CHAR(40), Password CHAR(40) PRIMARY KEY (ID) ) enum Status { New, CallLater, Converted, NotInterested } class Customer { int Id; string Name; Status Status; DateTime? ScheduledCall; string Email; string PhoneNumber; } CREATE TABLE Customers ( ID INTEGER, Name CHAR(40), Email CHAR(40), PhoneNumber CHAR(40), Status INTEGER, ScheduledCall DATETIME, PRIMARY KEY (ID) )
  11. class StatusChanged : IEvent { Status NewStatus; DateTime CreatedOn; int

    CreatedBy; } class FutureCallScheduled : IEvent { DateTime ScheduledCallTime; DateTime CreatedOn; int CreatedBy; } class ContactDetailsWereUpdated : IEvent { string NewName; string NewEmail; string NewPhone; DateTime CreatedOn; int CreatedBy; }
  12. class Customer { int Id; string Name; string Email; string

    PhoneNumber; Status Status; DateTime? ScheduledCall; List<IEvent> Events; … void Apply(StatusChanged e) { Status = e.NewStatus; Events.Add(e); } …. …. }
  13. class Customer { int Id; string Name; string Email; string

    PhoneNumber; Status Status; DateTime? ScheduledCall; List<IEvent> Events; … … void Apply(FutureCallScheduled e) { ScheduledCall = e.ScheduledCallTime; Events.Add(e); } … }
  14. class Customer { int Id; string Name; string Email; string

    PhoneNumber; Status Status; DateTime? ScheduledCall; List<IEvent> Events; … … … void Apply(ContactDetailsWereUpdated e) { Name = e.NewName; Email = e.NewEmail; PhoneNumber = e.NewPhoneNumber; Events.Add(e); } }
  15. class CustomerSearchModel { int Id; List<string> Names; List<string> Emails; List<string>

    PhoneNumbers; Status Status; DateTime? ScheduledCall; … … … void Apply(ContactDetailsWereUpdated e) { Names.Add(e.NewName); Emails.Add(e.NewEmail); PhoneNumbers.Add(e.NewPhoneNumber); } }
  16. class CustomerAnalysisModel { int Id; string Name; string Email; string

    PhoneNumber; List<StatusChange> StatusChanges; DateTime? ScheduledCall; … void Apply(StatusChanged e) { StatusChanges.Add( new StatusChange(e.CreatedOn, e.NewStatus) ); } …. …. }
  17. class Customer { int Id; string Name; string Email; string

    PhoneNumber; Status Status; DateTime? ScheduledCall; List<IEvent> Events; }
  18. class CustomerAnalysisModel { int Id; string Name; string Email; string

    PhoneNumber; List<StatusChange> StatusChanges; DateTime? ScheduledCall; }
  19. Good Domain Model • Not too much • Not too

    less • Sweet spot • The information we need • The information we might need
  20. Why domain models fail • We absolutely suck at predicting

    the future • No single model can suit all the use cases (e.g.: transactional processing, business intelligence, search) • Model transformations are painful
  21. • Event based models • Effective modeling • No future

    predicting required • Time machine • Retroactive debugging • Infrastructural freedom • Infinite scalability • Easy to scale writes • Easy to scale reads Conclusions
  22. Before you try this at home • Read “Implementing Domain

    Driven Design” by Vaughn Vernon • Read “Domain Driven Design” by Eric Evans • Follow Greg Young, Udi Dahan, DDD community • Read DDD/CQRS on Google Groups • Join http://meetup.com/DDD-IL :)