1. IntroductionCQRS Pieter Joost van de Sande

3. Thank you VSOFT!!

5. What CQRS changes to that

6. Building a CQRS architecture

7. Some demo stuff

8. Discussion

10. Typical architectures

11. Typical architectures Presentation Domain Data

13. Simple separation that is easy to explain.

14. Higher abstraction with each layer.

15. Known by a lot of people.

16. Supportedby tools andframeworks

18. Typical architectures

19. TWO fundamental things Every system has this

20. data

21. Transitions

22. What is CQRS? COMMAND QUERY RESPONSIBILITY SEGREGATION

23. Cqrs Concept Move from N-layer to…

24. N-LAYERarchitecture Presentation Domain Data

25. Presentation Domain Data

26. Presentation Domain Data

27. Presentation Domain Data

28. Presentation Read State transitions Domain Data

29. fromCQRS Concepttoarchitecture This adds more value!

31. User interface

32. Demand for data Because we have some screens to fill

33. WE read a lot

34. WE have multiple screens to fill

35. Data should be close to us

37. It shouldnot have toexecute business rules on the data.

38. It requests data manytimes.

39. It shouldbe close tous.

40. Getting data shouldbesimple (select * from x where y)Examples: Get all products of user X Get total price of all orders of month May

41. User interface

42. Read side User interface

43. Read side Read databases User interface

44. Read side Read databases query User interface

46. Contains the data in an form we need

47. Facades should be minimized

48. Read models do not have to be on one location...

50. Demand for change Otherwise things are static

51. I want to tell the system something Please move customer X to this new address

52. Change has intent Users don’t make changes for nothing. This intent has value! Correct the address for user X Customer X moved to new address VS.

53. Multiple steps Users can take multiple steps before they reach the end goal. These steps can be very useful to us.

55. Commands contain all the data needed to execute the underlying action.

56. Contain the intent of the change.Examples: AddProductToShoppingCart PurchaseOrder MoveUserToNewAddress CorrectAddressForUser

57. Read side Read databases query User interface

58. Read side Write side Read databases query User interface

59. Read side Write side Read databases Commandhandlers commands query User interface

60. Read side Write side Read databases Facade Domain Commandhandlers commands DTO’s User interface

61. Greg Young: “State transitions are an important part of our problem space and should be modeled within our domain.”

62. The ‘old’ domain model

63. Domain focused on behavior

64. Read side Write side Read databases Facade Domain Commandhandlers commands DTO’s User interface

65. Read side Write side Read databases Repository Facade Domain Commandhandlers commands DTO’s User interface

66. Read side Write side ? Read databases Repository Facade Domain Commandhandlers commands DTO’s User interface

68. Other systems use it for intergration.Examples ProductAddedToShoppingCart OrderPurchased UserMovedToNewAddress AddressCorrectedForUser

71. Read side Write side Denormalizers events Read databases Repository Facade Domain Commandhandlers commands DTO’s User interface

74. Event sourcing

75. Read side Write side events events Denormalizers Event bus events events Read databases Repository Facade Domain Commandhandlers commands DTO’s User interface

77. Contains the audit log

78. Read models can re-build themself of it

81. Allstate changes are represented by domainevents

82. The read models are updated as a resultof the published Events

84. Keep users intent

85. Bullet-proof auditing and historical tracing

86. No object-relational impedance mismatch

87. Optimized and multiple read models

88. Testability

90. Thankyou!You’ve been a great audience!