Event Sourcing RubySPBConf 2k18

Transcript

1. -> mail@davydovanton.com
   title: SPBRuby2k18
   

   View Slide

2. View Slide

3. View Slide

4. View Slide

5. View Slide

6. @palkan_tula
   

   View Slide

7. me
   

   View Slide

8. What I learned in
   Japan?
   

   View Slide

9. Ruby is still dying
   language
   

   View Slide

10. View Slide

11. Java is popular
    

    View Slide

12. View Slide

13. Pascal is popular
    too
    

    View Slide

14. View Slide

15. Best shell ever
    

    View Slide

16. View Slide

17. ❤

    

    Руддщ ЫЗИ!

    

    ❤
    

    View Slide

18. ❤

    

    Hello SPB!

    

    ❤
    

    View Slide

19. View Slide

20. View Slide

21. View Slide

22. Anton Davydov
    github.com/davydovanton

    twitter.com/anton_davydov
    davydovanton.com
    

    View Slide

23. • Software developer at Hippo
    • Hanami core developer
    • OpenSource evangelist
    

    View Slide

24. View Slide

25. Stickers
    

    View Slide

26. View Slide

27. Part 1: Real World
    

    View Slide

28. DEMO
    

    View Slide

29. Part 2: Software
    

    View Slide

30. View Slide

31. View Slide

32. View Slide

33. View Slide

34. View Slide

35. Pros
    • easy for understand
    • easy for implement
    

    View Slide

36. Cons
    • we have only current state of
    the system
    • impossible to understand what
    happened before
    

    View Slide

37. Sometimes we need
    more work for one event
    

    View Slide

38. Imagine what will happen
    if we will work only with
    events?
    

    View Slide

39. View Slide

40. View Slide

41. View Slide

42. View Slide

43. View Slide

44. Congrats, you know
    event sourcing!
    

    View Slide

45. Part 3: Event
    Sourcing
    

    View Slide

46. – Event Sourcing pattern

    https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing
    “Instead of storing just the current state of
    the data in a domain, use an append-only
    store to record the full series of actions taken
    on that data”
    

    View Slide

47. How to get
    business events?
    

    View Slide

48. Event Storming
    

    View Slide

49. DDD
    

    View Slide

50. Part 4: Event Store
    

    View Slide

51. View Slide

52. View Slide

53. Can be anything
    

    View Slide

54. View Slide

55. Rules
    

    View Slide

56. Immutable events
    

    View Slide

57. Immutable everything
    

    View Slide

58. How to store
    events?
    

    View Slide

59. View Slide

60. View Slide

61. View Slide

62. View Slide

63. View Slide

64. How get current
    state?
    

    View Slide

65. View Slide

66. View Slide

67. View Slide

68. View Slide

69. View Slide

70. View Slide

71. View Slide

72. View Slide

73. View Slide

74. View Slide

75. View Slide

76. View Slide

77. View Slide

78. View Slide

79. View Slide

80. How we can
    improve it?
    

    View Slide

81. View Slide

82. View Slide

83. View Slide

84. View Slide

85. View Slide

86. View Slide

87. View Slide

88. Part 5: Conclusions
    

    View Slide

89. Event Sourcing
    pros
    

    View Slide

90. Easier to communicate with
    domain experts
    

    View Slide

91. • time traveling
    • restore a system
    • logging out from box
    

    View Slide

92. • You don’t work with tables you work with
    events
    • Experemental data structures
    • Easy to change database implementations
    

    View Slide

93. • Easy to add instances for service
    • Can be written on any language
    and you can call it from any app
    • Persistance
    

    View Slide

94. event sourcing
    cons
    

    View Slide

95. • Hard for understand and
    complicated abstraction
    • Not popular in ruby and bad
    tooling here
    • Developers need deprogramming
    

    View Slide

96. • Hard to get state
    • Hard to understand the
    whole chain of events
    • Another architecture type

    with different DB structure
    

    View Slide

97. • Async world
    • Versions and versions
    compatibility
    • Updating or deleting events
    • Eventual Consistency
    

    View Slide

98. Part 6: Usage
    

    View Slide

99. Simple way
    

    View Slide

100. gems
     

     View Slide

101. View Slide

102. github.com/zilverline/sequent
     

     View Slide

103. Brave way
     

     View Slide

104. Build all stuff by self
     

     View Slide

105. View Slide

106. View Slide

107. View Slide

108. hanami-events
     

     View Slide

109. Just pub sub transport layer
     with event versions
     and types
     

     View Slide

110. microservices
     

     View Slide

111. microservices
     

     View Slide

112. View Slide

113. How to share
     state across DBs?
     

     View Slide

114. Idea #1: send data
     to specific service
     

     View Slide

115. View Slide

116. Problems
     

     View Slide

117. One service know
     about data from other
     

     View Slide

118. 1 -> N
     

     View Slide

119. View Slide

120. View Slide

121. Idea #2: events
     

     View Slide

122. View Slide

123. View Slide

124. View Slide

125. Important
     

     View Slide

126. Make events full
     as you can
     

     View Slide

127. View Slide

128. View Slide

129. View Slide

130. Part 7: Next Steps
     

     View Slide

131. CQRS

     

     (Command Query
     Responsibility Segregation)
     

     View Slide

132. – Martin Fowler
     “You can use a different model to
     update information than the model
     you use to read information”
     

     View Slide

133. View Slide

134. View Slide

135. View Slide

136. View Slide

137. View Slide

138. View Slide

139. DDD
     

     View Slide

140. View Slide

141. View Slide

142. View Slide

143. Books
     

     View Slide

144. View Slide

145. -> mail@davydovanton.com
     title: SPBRuby2k18
     

     View Slide

146. github.com/davydovanton

     twitter.com/anton_davydov
     davydovanton.com
     Thank you ❤
     

     View Slide