Cqrs 101 all your base belong to us

1,164 views

Published on

An intro into CQRS I gave for the Belgian Visual studio User group in March 2012

Published in: Technology, Spiritual
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,164
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
34
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Cqrs 101 all your base belong to us

  1. 1. CQRS 101All your BASE belong to usFirst dive into CQRS by Tom JanssensMarch 6th, 2012Hosted for VISUG.be by AE NV - Leuven, Belgium
  2. 2. Tom Janssens● Tom@corebvba.be● ToJans@twitter● http://www.corebvba.be/blog● http://github.com/ToJans● Fun Fact: 10 startups in one yearFreelance problem solver - contact me !
  3. 3. Y U NO CQRS ?● Occasionally disconnected client app● Google Groups Forum DDD/CQRS● CQRS articles on blog● OSS CQRS frameworks/libs:Scritchy & MinimalisticCQRS● Member of MS P & P CQRS advisory boardA.K.A. my CQRS background and - experience
  4. 4. OverviewTalk the talk● What● Why● WhenWalk the walkDemo BankAccount● MinimalisticCQRS● Uniqueness● Account transfer
  5. 5. WHAT: complexity evolutionSpaghetti approachUI Data layer
  6. 6. WHAT: complexity evolutionLasagna approach *:* Can contain additional layersUI App layer Data layerDomain layer
  7. 7. Command: change state - push data (state changes)Query: query state - pull dataWHAT: complexity evolution* Command-Query separation - Bertrand Meyer"Asking a question should not change the answer"CQS approach *:UI App layer Data layerAdvantages: Scaling, risk, impactUI App layer Data layerDomain layer
  8. 8. WHAT: complexity evolutionCQRS: Command Query Responsibility Segregation@Kellabyte on twitterThis is #CQRS http://bit.ly/zR2VuVThats it, thats all. What you put in behindthose is entirely up to you.
  9. 9. WHAT: complexity evolution// CQS (Command-Query Separation)// Bertrand Meyer devised the CQS principle// [deleted for brevity]public class CustomerService{// Commandsvoid MakeCustomerPreferred(CustomerId)void ChangeCustomerLocale(CustomerId, NewLocale)void CreateCustomer(Customer)void EditCustomerDetails(CustomerDetails)// QueriesCustomer GetCustomer(CustomerId)CustomerSet GetCustomersWithName(Name)CustomerSet GetPreferredCustomers()}
  10. 10. WHAT: complexity evolution// CQRS (Command-Query Responsibility Segregation)// Defined by Greg Young.// [deleted for brevity]public class CustomerWriteService{// Commandsvoid MakeCustomerPreferred(CustomerId)void ChangeCustomerLocale(CustomerId, NewLocale)void CreateCustomer(Customer)void EditCustomerDetails(CustomerDetails)}public class CustomerReadService{// QueriesCustomer GetCustomer(CustomerId)CustomerSet GetCustomersWithName(Name)CustomerSet GetPreferredCustomers()}
  11. 11. Thats all folks !!! The End !... Or not ?
  12. 12. Command: change state - push data (state changes)Query: build/query state - pull dataWHAT: complexity evolution* Command-Query Responsibility Segregation- Greg Young, Udi DahanCQRS approach *:"The creation of 2 objects where there previously was one"EventsUI Data layerUI Domain layerCommandsEventsbuildquery
  13. 13. What: messagesCommand● DoStuff !● Imperativevoid DoStuff( ... ){if (somethingtrue)apply(StuffDone);}Event● StuffDone● Past tensevoid Handle(StuffDone){SomeState = true;}IMPORTANT!!An event handler should ALWAYShave an immutable execution path,i.e. no logic !!
  14. 14. Command: change state - push data (state changes)Query: build/query state - pull dataWHAT: complexity evolutionCQRS approach *:Example code : Scritchy exampleEventsUI Data layerUI Domain layerCommandsEventsbuildquery
  15. 15. Why ?Clear separation of concernsDomainQuery sideUICommandsEventsupdateviewmodels"Circular architecture"Evolution of AlisterCockburns hexagonalarchitecture; no moreadapters needed
  16. 16. WhyClear separation of concerns● Requires different knowledge/other devs● Testability● Ubiquitous language● New business requirements
  17. 17. WhyEvent-driven architecture and the cloud:CAP theorem: pick 2ConsistencyAvailability Partitionability
  18. 18. Why: events & the cloudACID : Consistency & Availability● AtomicityAll operations complete, or none● Consistency(During a transaction)● IsolationEvery operation behaves as it is the only one● DurabilityFinished tx will not be reversed
  19. 19. Why: events & the cloudBASE : Availability & Partitionability● BasicallyAvailable● Soft state● Eventually consistent=> CLOUD !!!=> Solution for the consistency boundariesDDD: ARs & sagas
  20. 20. Why: events & the cloud
  21. 21. Why: events & the cloud
  22. 22. Why: events & the cloud
  23. 23. Why: events & the cloud
  24. 24. When to use CQRS ?Only apply it to the parts of your problemdomain that offer you a competitive advantage.Indicator for Complexity/uniqueness:=> T-shirt categories (Greg Young)CRUD - tell what cant be doneDDD - tell what can be doneref: free eBook "DDD quickly","What is DDD?"Works really well with DDD/ES=> When your problem domains are not fixed
  25. 25. BreakUp next - demo live coding
  26. 26. ConclusionWhat:Two objects where there previously was oneRemove layers and abstractionsCircular architecture=> Fire and forget
  27. 27. ConclusionWhy:Separation of concernsEvent driven architectureFlexibility, ScalabilityTestability
  28. 28. ConclusionWhen:ComplexityUniquenessCompetitive advantageParts of your problem domain
  29. 29. ThanksCQRS folks - for being such an avid community@YReynhout and @Abdullin for reviewVISUG.be and AE NV for hosting the event
  30. 30. Questions & feedback ?Twitter: @ToJans

×