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

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. hy
W
design
patterns ?

6. patterns

7. vocabulary

8. shared
understanding

9. hardest
of being a dev
?

10. tools
for managing
complexity

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
conflate
!
identity & state

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. query (read) side
simple
immutable
objects

28. command (write) side
simpler
domain
objects

29. command (write) side
tighter
domain objects

30. command (write) side
richer
domain

31. CQRS
benefits

32. CAP
CA vs AP

33. event sourcing

34. event sourcing
is not CQRS

35. identity
value & state

36. state
=
snapshot in time
=
sum of events
!

37. event sourcing

38. store
all the events

39. DDD

40. Add
A
to cart
Add
B
to cart
Remove
B
from cart
Add
C
to cart
Capture
order
address

41. Consumer
projects events
into data

42. Add
A
to cart
A
Add
B
to cart
Remove
B
from cart
Add
C
to cart
Capture
order
address

43. Add
A
to cart
Add
B
to cart
A
B
Remove
B
from cart
Add
C
to cart
Capture
order
address

44. Add
A
to cart
Add
B
to cart
Remove
B
from cart
A
Add
C
to cart
Capture
order
address

45. Add
A
to cart
Add
B
to cart
Remove
B
from cart
Add
C
to cart
A
C
Capture
order
address

46. Add
A
to cart
Add
B
to cart
Remove
B
from cart
Add
C
to cart
Capture
order
address
A
C

47. idea
project data
form(s) matching
requirements

48. project data
items removed
at checkout

49. project data
added then
removed often

50. project data
age of cart items

51. project data
other examples

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. commands
vs
events

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 nondevelopers

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. don’t use it for
cruddy apps
simple stuff
your entire app

71. DDD
bounded contexts

72. do consider it
where it fits

73. “
“
Seek simplicity,
and distrust it.
Alfred North Whitehead