This document provides an introduction and overview of CQRS (Command Query Responsibility Segregation). It discusses typical N-layer architectures and how CQRS changes the architecture by separating read and write operations. The key points are that CQRS moves the system from an N-layer to separating read and write concerns, with commands handling changes, events capturing changes, and read models optimized for queries and kept in sync with events. The document outlines the full flow from commands to events to updating read models and queries against the read models.

1. IntroductionCQRSPieter Joost van de Sande

3. Thank you VSOFT!!

4. AgendaHow we do things now

5. What CQRS changes to that

6. Building a CQRS architecture

7. Some demo stuff

8. Discussion

9. Beer!TypicalarchitecturesYou should recognize this

10. Typical architectures

11. Typical architecturesPresentationDomainData

12. N-LayerFlexible – we could replace a layer without breaking much.

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

17. Lots of resources availableWhat the n-tier tunnel brought us

18. Typical architectures

19. TWO fundamental thingsEvery system has this

20. data

21. Transitions

22. What is CQRS?COMMANDQUERYRESPONSIBILITYSEGREGATION

23. Cqrs ConceptMove from N-layer to…

24. N-LAYERarchitecturePresentationDomainData

25. PresentationDomainData

26. PresentationDomainData

27. PresentationDomainData

28. PresentationReadState transitionsDomainData

29. fromCQRS ConcepttoarchitectureThis adds more value!

31. User interface

32. Demand for dataBecause 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

36. Demandfor dataUser interface has different views tofill.

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 XGet total price of all orders of month May

41. User interface

42. Read sideUser interface

43. Read sideRead databasesUser interface

44. Read sideRead databasesqueryUser interface

45. Read sideThe only need it has to serve is reading.Do we need an relational data here?

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...

49. They should be close to the clientRead sideRead databasesqueryUser interface

50. Demand for changeOtherwise things are static

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

52. Change has intentUsers don’t make changes for nothing.This intent has value!Correct the address for user XCustomer X moved to new addressVS.

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

54. CommandsModel that is optimized the describe changes.

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

56. Contain the intent of the change.Examples:AddProductToShoppingCartPurchaseOrderMoveUserToNewAddressCorrectAddressForUser

57. Read sideRead databasesqueryUser interface

58. Read sideWrite sideRead databasesqueryUser interface

59. Read sideWrite sideRead databasesCommandhandlerscommandsqueryUser interface

60. Read sideWrite sideRead databasesFacadeDomainCommandhandlerscommandsDTO’sUser 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