As Grails developers we reflexively lean on the default pattern for data storage: a single row represents the current state of a Domain Object. For most applications, only ever knowing the current state is just fine. However, understanding the manipulations that got your data to that state are just as important as the current state itself, especially in a large system with multiple users. Enter Event Sourcing: instead of persisting the current state of our Domain Objects, we store historical events about our data. In this talk I will discuss the basic concepts of Event Sourcing. We will discuss the advantages – particularly around performance and analytics – and disadvantages of using this pattern. We will see how easily it can be implemented in Groovy and used within a Grails application. Finally, we’ll examine some practical use cases and when one would consider implementation. Additionally, there's a code demo that is not covered in the slides, but can be found here: https://github.com/spember/greach2014-es-demo

1. Groovier Data History with Event
Sourcing
Greach 2014

2. Web / Business Analytics
Meet Bob
2

3. 3

4. 4

5. 5

6. 6

7. 7
What do you have to offer?

8. 8
State of Your Data

9. 9

10. 10

11. 11

12. 12

13. 13

14. 14
Balance: $100

15. 15
Balance: -$100

16. 16

17. 17

18. 18

19. 19

20. 20
Maintaining Only the Current State is a limitation
Historical Data can be important

21. 21
Event Sourcing

22. No Direct Manipulation of State

23. 23

24. 24

25. Events are a Timeline

26. 26

27. 27

28. 28

29. 29

30. 30

31. 31

32. 32

33. 33

34. 34
Current State Is Only
One PROJECTION

35. 35
Create other Views

36. 36

37. IT
HURTS
37

38. Grocery Store shopping cart
38

39. E Commerce Shopping cart
39

40. 40

41. 41

42. Scenarios:
42
• Discover if Users are Adding and Removing Products: Give them a
discount to encourage purchase
• Time between adding products and purchase
• Frequency between cart events and other system events

43. Bob is
Pleased
43

44. Not a New Concept

45. 45

46. 46

47. 47

48. 48

49. 49
Wait, what about
those transaction logs?

50. 50

51. 51

52. 52
Audit Log will tell the history
Events tell you the Intent of history

53. 53
Implementation

54. 54

55. 55

56. 56

57. 57

58. 58

59. 59

60. 60

61. 61

62. 62
Creating an Event Store

63. 63
Aggregate
(it’s like a Domain Instance)

64. 64

65. Events
65

66. 66

67. 67

68. 68

69. 69

70. 70
Snapshots: essential optimization

71. 71

72. 72

73. 73
Choosing a Persistance Layer

74. 74
No real need for an ORM

75. Data base agnostic

76. Consider Using a Relational Database
76

77. 77

78. 78

79. 79
Demo Time

80. 80
… But Should I use it?

81. Use it only for Business-Critical data

82. Make Bob Happy
82

83. Thank You!

84. Questions
?

85. Image References
(Multiple Newspapers): http://www.kba.com/gb/news/detail/article/30-kba-newspaper-customers-carry-off-quality-awards-2/back/50/
(Harbor): http://www.dredgingtoday.com/2013/09/06/corps-highlights-economic-benefits-of-savannah-harbor-dredging-usa/
(Sad Bob) http://workerscompensationwatch.com/2012/12/
(Logs in River / Log Driving) http://www.flickr.com/photos/foresthistory/
(Data Base Transaction Log) http://yutechnet.com/?p=96
(Amazon Shopping Cart) http://www.amazon.com
(Ha, Ha, Business) http://www.quickmeme.com
(crowd of people) http://www.flickr.com/photos/jamescridland/613445810/
(skeptical dog) http://loltheists.com/?p=2427
(brick layer) http://www.torange.us/photo/4/13/brick-mud-brick-building-1259649354_44.jpg