communityday 2012 - cqrs

527 views

Published on

Published in: Technology, Economy & Finance
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
527
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

communityday 2012 - cqrs

  1. 1. CQRSTim Mahy
  2. 2. Agenda• Why – History – Current architectures & challenges• What• Real life case
  3. 3. • Command• Query• Responsibility• Segregation
  4. 4. • About the business and looking at the business with regards to – collaboration• Not only for high-scalability requirements• A set of difficult questions• A fresh look at architecture and code design
  5. 5. • Touches – DDD – NoSQL – BDD – EDA
  6. 6. • TODO: Data Entry screen for a company
  7. 7. But what has changed• Increase of – Commands – Queries – Searching – Users and Collaboration
  8. 8. Collaboration• Locking strategies
  9. 9. Traditional architectureTODO:• Layers / Tiers• Transformations• Structured data
  10. 10. Let’s validate this design• TODO: validate against new challenges• + talk a bit about caching and ORM etc
  11. 11. <asp:DataList ID="DataList1" runat="server" DataSourceID="LastUsersDataSource"> <ItemTemplate> <asp:Label ID="NameLabel" runat="server" Text=<%# Eval("Name") %> /> <br /> 2 layer </ItemTemplate></asp:DataList><asp:SqlDataSource ID="LastUsersDataSource" runat="server" ConnectionString="<%$ConnectionStringsMyConnectionString %>" Query model SelectCommand="SELECT [Name], [InsertDateTime] FROM [LastUsers] ORDER BY [InsertDateTime] DESC"></asp:SqlDataSource>
  12. 12. Let’s go back to the essence• Pattern to segregate approach for: – Commands – Queries• Everything in ALM is touched by this
  13. 13. Commands• Task driven UI
  14. 14. Commands• Serialized method call on a root aggregate• Can say NO• Check business rules• Can be sync/async• Work best in a DDD world – 3 layered – No more worries for ‘slow’ reading
  15. 15. Queries• Is not search!! – Lucene.NET – Google applieance
  16. 16. Queries• Stale dataTODO: Mockup  straten
  17. 17. Queries• Return DTO• Less layered approach• Have their own state (persisted viewmodel)• No influence on command side• Easy domain• Datastore  does it need to be relational?
  18. 18. But how do we come to these persisted viewmodels• Commands deliver business events (past tense)• Business events mutate state on truth datastore and in persisted viewmodels
  19. 19. UI DataStore Queries SubscribeUI Commands EventBus Business Logic Publish Truth (optional)
  20. 20. Business events sourcing• Keep all business events• Replay business events when needed – Snapshotting strategy when required• Truth database can also be only these events in an ideal world
  21. 21. • Demo: event sourcing shopping cart
  22. 22. Other team members• Testing – Given * events – When * command – Then * events
  23. 23. Tooling• SimpleCQRS• NServiceBus
  24. 24. Real life case• VECOZO• Project• Requirements• How CQRS helped us• Statistics
  25. 25. Project• Receives all the health insurance information from the Netherlands• Allow healtcare parties query to check for insurance and details• Give insights back to the insurance companies and government
  26. 26. Requirements• Every query should respond below 20ms• Traditional .NET stack: – MS SQLServer 2008 R2 – WCF SOAP webservices• Must be able to respond to 600 query requests per second• Must be able to process all data within 4 hours
  27. 27. CQRS (zoals meest bekend) UI DataStore Queries SubscribeUI Commands EventBus Business Logic Publish Truth (optional)
  28. 28. CQRS (zoals in AVG) DataStoreWebserv Queries Receive ices EventBus Commands PCS Business Logic Publish changes Truth
  29. 29. Technical choices• Event Sourcing is stored in MS SQLServer• All queues are Sql Server Service Broker Queues• Denormalizers are CLR stored procedures in query databases• Query databases are all eventually consistent, no synchronisation context over health insurance companies – Very hard normalized (one table) – Dirty reads – Correction of data in-memory after reading
  30. 30. Statistics & Conclusion• Statistics: – Event Sourcing: 190 GB – Persisted views: 80 GB – 72 health insurance companies deliver 80M insurance packages a day which are validated with commands – Which results in 169.000 business events a day• Very easy to test• Very easy to manage when – Failure – Failover• Staged deployment• Future proof – No more migrations ever – New systems just need to understand the business events
  31. 31. POC Event Sourcing: QueueUnlimited
  32. 32. QueueUnlimited• Open Source project• Very easy architecture for event sourcing
  33. 33. Queue Unlimited – no subscribers• How it works PublishEvent SP InitiatorService RootService Stored Procedure SSB Service SSB Queue enabled SSB Queue disabled Activation SP enabled Activation SP disabled SSB Dialog / Send
  34. 34. Queue Unlimited – Adding a subscriber PublishEvent SP InitiatorService RootService Activated Subscriber 1 Service Replay 1 Service Not activated Some app
  35. 35. QUEUE UNLIMITED – Adding another subscriber SendEvent SP Initiator service Root Service Activated Subscriber 1 Service Replay 1 Service Activated Some app Not Subscriber 2 Service Replay 2 Service activated Some app
  36. 36. QUEUE UNLIMITED – Garbage collection SendEvent SP Initiator service Root Service Activated Not Subscriber 1 Service Subscriber 2 Service Replay 2 Service activated Some app Some app
  37. 37. QUEUE UNLIMITED – Scale outSendEvent SP Initiator service Root Service 30% messages Subscriber 1 Service Replay 1 Service 30% messages Some app Replay 1 Service 2 Replay 1 Service 3 40% messages 42

×