Why Cqrs


Published on

Why: CQRS is the new 'hotness' but beyond a desire to use the latest 'fad' what might actually lead you to adopt this approach over a conventional layered architecture. Looking back we will explore how some of the debates in the DDD community about how to implement Eric Evans ideas led people to the CQRS solution. We will look at some of the problems with aggregates and repositories that CQRS helps with and how the vision of seperating core from other domains is simplified. We will also look at simple steps to begin moving your layered application in the CQRS direction and give you a taste of what is to come. By the end of this session you should understand the problems that transitioning to CQRS will help you to resolve.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Why Cqrs

  1. 1. Just  flash  fashion  or  a  classic  
  2. 2. Who  are  you?     Software  Developer  for  18  years     Worked  mainly  for  ISVs     Reuters,  SunGard,  Misys     Worked  for  a  couple  of  MIS  departments     DTI,  Beazley     Microsoft  MVP  for  C#     Interested  in  OO  design     Interested  in  Agile  methodologies  and  practices     No  smart  guys     Just  the  guys  in  this  room   Ian  Cooper                                                                                                                www.codebetter.com  
  3. 3. Agenda   •  here  did  it  all  go  wrong?   W •  he  problem  with  N-­‐Tier   T •  QRS  to  the  rescue   C •  emo  probably  here   D •  oing  further   G Ian  Cooper                                                                                                                www.codebetter.com  
  4. 4. Where  did  it  all  go  wrong   Why  the  N-­‐Tier  architecture  party  is  over.   Ian  Cooper                                                                                                                www.codebetter.com  
  5. 5. The  Electronic  File   Ian  Cooper                                                                                                                www.codebetter.com  
  6. 6. The  Data  Entry  Screen   Ian  Cooper                                                                                                                www.codebetter.com  
  7. 7. Brave  New  World     No  just  about  paper  input  any  more     But  architecture  still  reflects  that  idea     We  need  to  reflect  that  landscape   Ian  Cooper                                                                                                                www.codebetter.com  
  8. 8. The  problem  of  CRUD   Why  are  we  failing?   Ian  Cooper                                                                                                                www.codebetter.com  
  9. 9. RTFM   Ian  Cooper                                                                                                                www.codebetter.com  
  10. 10. The  Old  Software  Lifecycle     Software  design  began  with  CRUD     Data  Flow  Diagrams     Process  Diagrams     IT  made  it  all  about  the  data     But  it  was  really  all  about  the  goal     What  was  the  data  used  for     Ian  Cooper                                                                                                                www.codebetter.com  
  11. 11. But  what  about  MI     Just  capturing  data  to  report  it     But  what  happens  if  we  want  to  report  something   new?     The  address  change  problem.     Rarely  the  goal     Reports  are  part  of  a  process     What  do  we  do  with  that  report?   Ian  Cooper                                                                                                                www.codebetter.com  
  12. 12. Insidious  CRUD     This  might  be  good  for  ‘catalogue  data’     But  beware…     If  I  set  state  through  CRUD  how  do  I  know  what  to   set?     The  manual…     Existing  Business  Process     If  the  domain  model  is  the  rules     Don’t  make  the  user  the  domain  model   Ian  Cooper                                                                                                                www.codebetter.com  
  13. 13. Is  it  appropriate?   Ian  Cooper                                                                                                                www.codebetter.com  
  14. 14. CQRS  to  the  rescue!   Of  course  there  is  no  silver  bullet…   Ian  Cooper                                                                                                                www.codebetter.com  
  15. 15. Some  N-­‐Tier  problems   Ian  Cooper                                                                                                                www.codebetter.com  
  16. 16. Breaking  out  commands   Ian  Cooper                                                                                                                www.codebetter.com  
  17. 17. Diets  can  be  healthy   Ian  Cooper                                                                                                                www.codebetter.com  
  18. 18. Beware  Vampires   Ian  Cooper                                                                                                                www.codebetter.com  
  19. 19. Handling  a  Command     Load  everything  we  need  via  infrastructure.     Usually  we  only  have  one  aggregate  from  repository.        May  have  other  stuff  such  as  information  from  web   service  calls     Exercise  one  method  on  the  aggregate  root     This  method  is  here  to  keep  us  from  bleeding  business   logic  into  the  command  handler     If  we  need  more  than  one  aggregate  involved   we  raise  an  event  for  other  aggregate  roots  to   handle     Persist  and  clean  up  via  infrastructure   Ian  Cooper                                                                                                                www.codebetter.com  
  20. 20. Query  Questions  Answered   Ian  Cooper                                                                                                                www.codebetter.com  
  21. 21. Data  Structures  and  Objects     Data  Structure     Has  public  state  but  not  behavior     Class     Has  behavior,  encapsulates  state   Ian  Cooper                                                                                                                www.codebetter.com  
  22. 22. Two-­‐Tier  is  Enough   Presentation   Infrastructure   DB   Ian  Cooper                                                                                                                www.codebetter.com  
  23. 23. Show  Us  Some  Code  Then!     We  wander  around  some  demo  code     We  will  try  to  show  the  steps  to  CQRS     Though  be  warned  it  may  get  scrappy   Ian  Cooper                                                                                                                www.codebetter.com  
  24. 24. Going  Further   Command-­‐Query  separation  first  step  on  journey  of   a  thousand  miles   Ian  Cooper                                                                                                                www.codebetter.com  
  25. 25. Event  Sourcing   Ian  Cooper                                                                                                                www.codebetter.com  
  26. 26. Ian  Cooper                                                                                                                www.codebetter.com  
  27. 27. Eventual  Consistency   Ian  Cooper                                                                                                                www.codebetter.com  
  28. 28. No  one  will  do  that!   How  to  overcome  doubts  on  cost   Ian  Cooper                                                                                                                www.codebetter.com  
  29. 29. Strategic  Design     Strategic  Design     Core     Supporting       Generic   Ian  Cooper                                                                                                                www.codebetter.com  
  30. 30. CQRS  –  Command  and  Query  Responsibility  Segregation   •  oby  Henderson   T •  holytshirt   @ •  endersont@gmail.com   h •  ttp://holytshirt.blogspot.com   h
  31. 31. CQRS  C#  example     http://github.com/MarkNijhof/Fohjin     ttp://bit.ly/prognetcqrs   h   Mark  Nijhof     http://elegantcode.com/about/mark-­‐nijhof/  
  32. 32. Queries  –  CQS       Return  a  result  and  do  not  change  the   observable  state  of  the  system  (are  free  of   side  effects).  -­‐  “Bertrand  Meyer”     Asking  a  question  should  not  change  the   answer.  
  33. 33. Queries  –  CQRS     Any  need  for  data  from  the  system  is  a   reporting  need;  this  includes  the  various   application  screens  which  the  user  uses  to   base  his  decisions  on.  –  Greg  Young     Showing  user  information  involves  no   business  behaviour  and  is  all  about  opening   up  that  data.  –  Udi  Dahan  
  34. 34. Before  CQRS   CompanyService   void  CreateCompany(Company)   Company  GetCompany(CompanyId)     List<Company>  GetCompaniesWithName(Name)     void  EditCompanyDetails(CompanyDetails)   void  Delete  Company(CompanyId)  
  35. 35. Applying  CQRS   CompanyWriteService   void  CreateCompany(Company)     void  EditCompanyDetails(CompanyDetails)   void  DeleteCompany(CompanyId)   CompanyReadService   Company  GetCompany(CompanyId)     List<Company>  GetCompaniesWithName(Name)    
  36. 36. Database   Data   Domain  Model   Read   Write   DTO   View  Model   View  
  37. 37. Database   Data   Data   Domain  Model   Read   Write   Services   View  Model   View  Model   View   View  
  38. 38. Sync   Database   Database   Data   Data   Domain  Model   Read   Write   Services   View  Model   View  Model   View   View  
  39. 39. Sync   Database   Data   Read   View  Model   View  
  40. 40. Store  View  Model     Put  ViewModel  in  the  database  /  storage.     A  table  for  each  view  or  as  much  as  the  view   as  possible.     Very  fast  with  little  or  no  transformation.     Database  can  become  a  cache.     No  need  for  ORM.     Cheap.     Data  is  stale  anyway.  
  41. 41. @NeilRobbins   neil@computer.org  
  42. 42. Don  Box’s  4  Tenets  of  SOA     Boundaries  are  explicit     Services  are  autonomous     Services  share  schema  and  contract,  not  class     Service  compatibility  is  determined  based  on   policy  
  43. 43. The  Open  Groups  Definition  of  a   Service     Is  a  logical  representation  of  a  repeatable   business  activity  that  has  a  specified  outcome   (e.g.,  check  customer  credit,  provide  weather   data,  consolidate  drilling  reports)     Is  self-­‐contained     May  be  composed  of  other  services     Is  a  “black  box”  to  consumers  of  the  service     From:  http://www.opengroup.org/soa/source-­‐book/soa/soa.htm
  44. 44. Some  Visions  of  SOA   “Implementing  SOA  the  right  way   The  figure  below  depicts  a  well-­‐designed  SOA.”   IMO  –  A  Vendors   wet-­‐dream   All  in  terms  of   infrastructure,  none  in   terms  of  business!   From:  http://www.javaworld.com/javaworld/jw-­‐11-­‐2006/jw-­‐1129-­‐soa.html?page=3  
  45. 45. Some  Visions  of  SOA   From:  http://www.ibm.com/developerworks/webservices/library/ws-­‐WSBFoverviewpart1/index.html  
  46. 46. Some  Visions  of  SOA   From:  http://www.infoq.com/articles/SOA-­‐enterprise-­‐data  
  47. 47. A  Vision  of  SOA   Composite  UI  
  48. 48. A  Vision  of  SOA   Shopping   Cart  Service   Command   Command   Ratings  Service   Command   Product   Command   Images  Service   Command   Command   Command   Buying  Choices   Service   Bought  Together   Offers  Service   Service  
  49. 49. A  Vision  of  SOA   Composite  UI  (also  a  service)   Shopping   Bought   Product   Ratings   Offers   Cart   Together   Images   Service   Service   Service   Service   Service  
  50. 50. Not  just  aligned  with  Business   Activity       So  each  service  has  its  own  requirements     Not  just  the  ‘strictly’  functional     So  what  might  we  consider  
  51. 51. Yield     AKA  Availability     A  measure  of  the  probability  of  completing  a   request     Typically  measured  in  9s  (eg  0.9999)     A  very  common  measure  in  SLAs  
  52. 52. Harvest