CQRS

A quick look at CQRS and event sourcing, advantages and pitfalls, and how they influence design decisions.

Transcript

1. CQRS
   and friends *
2. me
   @luke_randall github.com/
3. A bad design with a test suite is still a bad design Rich Hickey “ “
4. design patterns
5. design patterns Why ?
6. patterns
7. vocabulary
8. shared understanding
9. of being a dev hardest ? ?
10. for managing complexity tools
11. value
12. value immutable dat
13. identity
14. identity values over time
15. state
16. state snapshot in time
17. identity ≠ state
18. objects ! identity & state conflate
19. CQRS
20. command
21. command
    query
22. command
    query
    responsibility
23. command
    query
    responsibility
    segregation
24. cf.
    command
    query
    separation
25. command
    ≠
    query
26. vs. crud
27. simple immutable objects query (read) side
28. simpler domain objects command (write) side
29. tighter domain objects command (write) side
30. richer domain command (write) side
31. benefits CQRS
32. CA vs AP CAP
33. event sourcing
34. event sourcing is not CQRS
35. identity value & state
36. state
    =
    ! =
    sum of events snapshot in time
37. event sourcing
38. store the events all
39. DDD
40. Add B to cart Add A to cart Remove B from cart Add C to cart Capture order address
41. Consumer
    projects events into data
42. Add B to cart Add A to cart Remove B from cart Add C to cart Capture order address A
43. Add B to cart Add A to cart Remove B from cart Add C to cart Capture order address A B
44. Add B to cart Add A to cart Remove B from cart Add C to cart Capture order address A
45. Add B to cart Add A to cart Remove B from cart Add C to cart Capture order address A C
46. Add B to cart Add A to cart Remove B from cart Add C to cart Capture order address A C
47. form(s) matching requirements idea project data
48. items removed at checkout project data
49. added then removed often project data
50. age of cart items project data
51. other examples project data
52. less complexity
    simpler models
53. flexibility
    many simpler schemas
54. scalability
    append only
55. scalability
    append only
56. flexibility
    no migrating schemas
57. millions of events
    snapshots
58. vs
    events commands
59. testing commands
    play event log
60. testing commands
    can never be in an invalid state
61. testing commands
    expectations in terms of events
62. given
    a list of events when
    I run a command expect
    an event
63. understandable tests
    for non- developers
64. eventual consistency
    must be dealt with
65. benefits
66. benefits of a complete history
67. benefits of a complete history of everything
68. benefits of a complete history of everything ever
69. disadvantages/gotchas
    consistency
    mental model
70. cruddy apps
    simple stuff your entire app don’t use it for
71. bounded contexts DDD
72. where it fits do consider it
73. Seek simplicity, and distrust it. Alfred North Whitehead “ “