Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduction to Event Sourcing and CQRS (IASA-IL)

5,343 views

Published on

Slides for my "Introduction to Event Sourcing and CQRS" session at the IASA-IL meeting.

Abstract:
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.

Published in: Technology
  • Be the first to comment

Introduction to Event Sourcing and CQRS (IASA-IL)

  1. 1. Introduction to Event Sourcing … and CQRS
  2. 2. Vladik Khononov Chief Architect at Internovus http://il.linkedin.com/in/vladikkhononov/ vladikk vladikkhttp://vladikk.com
  3. 3. Information Systems
  4. 4. HTML5AngularJSWPFIOSFlashExtJSAndroidSilverlight Responsive webdesign SPACSS3 User Interface
  5. 5. User Interface MySQLMongoDBDynamoDBNeo4jRavenDBPostgreSQLHBaseCassandraSql ServerMariaDBRedisCouchDB Data Access
  6. 6. User Interface Data Access “Verbs & Nouns”Domain Driven Design Business Logic
  7. 7. Domain Driven Design?
  8. 8. User Interface Business Logic Data Access
  9. 9. – www.dictionary.com Model: A simplified representation of a system or phenomenon. – www.wikipedia.org ‫:מודל‬ ‫ייצוג‬‫תאורטי‬‫של‬‫מערכת‬‫מורכבת‬ , ‫שמטרתו‬ ‫לחקות‬‫את‬‫המערכת‬‫בהיבטים‬‫מהותיים‬ . ‫המודל‬‫אינו‬ ‫מתאר‬‫כל‬‫תופעה‬‫במערכת‬ , ‫אלא‬‫מתייחס‬‫להיבטים‬ ‫מוגדרים‬‫ומצומצמים‬‫שלה‬ . ‫המודל‬‫מבוסס‬‫על‬‫קירוב‬‫של‬ ‫המציאות‬‫בדרך‬‫של‬‫הפשטה‬ , ‫איחוד‬‫ישויות‬‫והתעלמות‬ ‫מגורמים‬‫שהשפעתם‬‫אינה‬‫מהותית‬ .
  10. 10. User Interface Business Logic Data Access
  11. 11. Domain Model
  12. 12. Good Domain Model • Not too much • Not too less • Sweet spot • The information we need • The information we will need
  13. 13. Why domain models fail • We absolutely suck at predicting the future • No single model can suit all the use cases • Model transformations are painful
  14. 14. Case Study: Customers Management
  15. 15. • 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)
  16. 16. • 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
  17. 17. 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) )
  18. 18. • 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
  19. 19. • 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
  20. 20. • Analysts should be able to review status changes history for each customer - change date and the new status
  21. 21. 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) )
  22. 22. Id Name Email Phone number Status Scheduled Call 10 John john@gmail.com 04-2342343 New
  23. 23. Id Name Email Phone number Status Scheduled Call 10 John john@gmail.com 04-2342343 CallLater 27/10/2014
  24. 24. Id Name Email Phone number Status Scheduled Call 10 John john@gmail.com 08-9876653 CallLater 27/10/2014
  25. 25. Id Name Email Phone number Status Scheduled Call 10 John john@gmail.com 08-9876653 Converted
  26. 26. Id Name Email Phone number Status Scheduled Call 10 John john@gmail.com 08-9876653 Converted
  27. 27. Event Sourcing Capture all changes to an application state as a sequence of events ~ Martin Fowler
  28. 28. 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; }
  29. 29. 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); } …. …. }
  30. 30. 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); } … }
  31. 31. 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); } }
  32. 32. Id Name Email Phone number Status Scheduled Call 10 John john@gmail.com 08-9876653 Converted
  33. 33. 1. new StatusChanged(Status.CallLater) 2. new FutureCallScheduled(’27/10/2014’) 3. new ContactDetailsWereUpdated( NewPhoneNumber=’08-9876653’ ) 4. new StatusChanged(Status.Converted)
  34. 34. Event Storage Entity Id + New events Entity IdEvent1, Event2, Event3, ….
  35. 35. 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); } }
  36. 36. 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) ); } …. …. }
  37. 37. class Customer { int Id; string Name; string Email; string PhoneNumber; Status Status; DateTime? ScheduledCall; List<IEvent> Events; }
  38. 38. class CustomerSearchModel { int Id; List<string> Names; List<string> Emails; List<string> PhoneNumbers; Status Status; DateTime? ScheduledCall; }
  39. 39. class CustomerAnalysisModel { int Id; string Name; string Email; string PhoneNumber; List<StatusChange> StatusChanges; DateTime? ScheduledCall; }
  40. 40. Good Domain Model • Not too much • Not too less • Sweet spot • The information we need • The information we might need
  41. 41. 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
  42. 42. Event Storage Entity Id + New events Entity IdEvent1, Event2, Event3, ….
  43. 43. CQRS Command Query Responsibility Segregation
  44. 44. • 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
  45. 45. Bounded Contexts
  46. 46. Domain Types • Core Domain • Subdomain • Generic Subdomain
  47. 47. Plexop
  48. 48. Campaign Management (Core Domain) Creative Catalog (Subdomain) User Management (Generic Subdomain) Billing (Generic Subdomain)
  49. 49. 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 :)
  50. 50. Questions?
  51. 51. http://il.linkedin.com/in/vladikkhononov http://twitter.com/vladikk http://vladikk.com

×