Advertisement
Advertisement

More Related Content

Advertisement
Advertisement

Introduction to Event Sourcing and CQRS (IASA-IL)

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