Event Sourcing RubySPBConf 2k18

Transcript

1. -> mail@davydovanton.com title: SPBRuby2k18
6. @palkan_tula
7. me
8. What I learned in Japan?
9. Ruby is still dying language
11. Java is popular
13. Pascal is popular too
15. Best shell ever
17. ❤
 
 Руддщ ЫЗИ!
 
 ❤
18. ❤
 
 Hello SPB!
 
 ❤
22. Anton Davydov github.com/davydovanton
 twitter.com/anton_davydov davydovanton.com
23. • Software developer at Hippo • Hanami core developer • OpenSource evangelist
25. Stickers
27. Part 1: Real World
28. DEMO
29. Part 2: Software
35. Pros • easy for understand • easy for implement
36. Cons • we have only current state of the system • impossible to understand what happened before
37. Sometimes we need more work for one event
38. Imagine what will happen if we will work only with events?
44. Congrats, you know event sourcing!
45. Part 3: Event Sourcing
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”
47. How to get business events?
48. Event Storming
49. DDD
50. Part 4: Event Store
53. Can be anything
55. Rules
56. Immutable events
57. Immutable everything
58. How to store events?
64. How get current state?
80. How we can improve it?
88. Part 5: Conclusions
89. Event Sourcing pros
90. Easier to communicate with domain experts
91. • time traveling • restore a system • logging out from box
92. • You don’t work with tables you work with events • Experemental data structures • Easy to change database implementations
93. • Easy to add instances for service • Can be written on any language and you can call it from any app • Persistance
94. event sourcing cons
95. • Hard for understand and complicated abstraction • Not popular in ruby and bad tooling here • Developers need deprogramming
96. • Hard to get state • Hard to understand the whole chain of events • Another architecture type
 with different DB structure
97. • Async world • Versions and versions compatibility • Updating or deleting events • Eventual Consistency
98. Part 6: Usage
99. Simple way
100. gems
102. github.com/zilverline/sequent
103. Brave way
104. Build all stuff by self
108. hanami-events
109. Just pub sub transport layer with event versions and types
110. microservices
111. microservices
113. How to share state across DBs?
114. Idea #1: send data to specific service
116. Problems
117. One service know about data from other
118. 1 -> N
121. Idea #2: events
125. Important
126. Make events full as you can
130. Part 7: Next Steps
131. CQRS
 
 (Command Query Responsibility Segregation)
132. – Martin Fowler “You can use a different model to update information than the model you use to read information”
139. DDD
143. Books
145. -> mail@davydovanton.com title: SPBRuby2k18
146. github.com/davydovanton
 twitter.com/anton_davydov davydovanton.com Thank you ❤