Event sourcing and cqrs for dummies

HoWest 27/05/2025

A short journey through the what, why and how of event sourcing. So that you know what the accompanying practices & patterns are. But also how you can get started with it and what accompanying pathrens and practices are

Transcript

1. © ZF Friedrichshafen AG Event Sourcing and CQRS for dummies Kim Van Renterghem
2. © ZF Friedrichshafen AG KEY FACTS Who Am I? 2024-06-20 | SCALAR Community of Practice for Devs 2 Kim Van Renterghem Developer since 2008 Senior developer @ zf-scalar kim-van-renterghem
3. © ZF Friedrichshafen AG Traditional systems 3 2024-06-20 | SCALAR Community of Practice for Devs CRUD
4. © ZF Friedrichshafen AG Whenever we change something, we lose the previous state 2024-06-20 | SCALAR Community of Practice for Devs 4
5. © ZF Friedrichshafen AG When you change tracking/detection becomes difficult 2024-06-20 | SCALAR Community of Practice for Devs 5
6. © ZF Friedrichshafen AG Bugs are causing an inconsistent state => by correcting you often create a vicious circle 2024-06-20 | SCALAR Community of Practice for Devs 6
7. © ZF Friedrichshafen AG When there are audits, it is impossible to prove that the state is correct. There are no guarantees that every change is logged because the updates and the audit log do not happen in the same transaction. 2024-06-20 | SCALAR Community of Practice for Devs 7
8. © ZF Friedrichshafen AG Logs 2024-06-20 | SCALAR Community of Practice for Devs 8 To the Rescue!
9. © ZF Friedrichshafen AG Logs 2024-06-20 | SCALAR Community of Practice for Devs 9 Shows when and what changes
10. © ZF Friedrichshafen AG Logs 2024-06-20 | SCALAR Community of Practice for Devs 10 Logs are difficult to handle because they do not look at the changes but at the consequences of actions.
11. © ZF Friedrichshafen AG Logs 2024-06-20 | SCALAR Community of Practice for Devs 11 They are also not about an entity but about all transactions in a domain. often even about steps we take within a process.
12. © ZF Friedrichshafen AG Logs 2024-06-20 | SCALAR Community of Practice for Devs 12 They show when something changes. => But not how or why.
13. © ZF Friedrichshafen AG Logs 2024-06-20 | SCALAR Community of Practice for Devs 13 They do not leave audit trails. These are often added. But in turn are also not reliable.
14. © ZF Friedrichshafen AG What if we now used our logs as "the only source of truth“ 2024-06-20 | SCALAR Community of Practice for Devs 14
15. © ZF Friedrichshafen AG What if we now used our logs as "the only source of truth“ 2024-06-20 | SCALAR Community of Practice for Devs 15 Let the logs be about the transitions of the past for example: • Table reserved • Two martinis ordered • Martinis delivered • A steak with fries ordered • ... • Bill paid • Table left
16. © ZF Friedrichshafen AG What if we now used our logs as "the only source of truth“ 2024-06-20 | SCALAR Community of Practice for Devs 16 You always start with a created event • Table reserved
17. © ZF Friedrichshafen AG What if we now used our logs as "the only source of truth“ 2024-06-20 | SCALAR Community of Practice for Devs 17 • Should be add only • 10l red wine ordered • 10l red wine order cancelled • 1l red wine ordered no removing or adjusting!
18. © ZF Friedrichshafen AG What if we now used our logs as "the only source of truth“ 2024-06-20 | SCALAR Community of Practice for Devs 18 • use structured data such as a document store or json document
19. © ZF Friedrichshafen AG What if we now used our logs as "the only source of truth“ 2024-06-20 | SCALAR Community of Practice for Devs 19 • Now you have time in your model and the sum of all transitions is the current state
20. © ZF Friedrichshafen AG What if we now used our logs as "the only source of truth“ 2024-06-20 | SCALAR Community of Practice for Devs 20 When stream ends, mark it with an event • Dinner paid • Guests left
21. © ZF Friedrichshafen AG This is what we call “Event sourcing” 2024-06-20 | SCALAR Community of Practice for Devs 21 Instead of a table with rows for entities. Use a stream for each aggregate.
22. © ZF Friedrichshafen AG This is what we call “Event sourcing” 2024-06-20 | SCALAR Community of Practice for Devs 22 Domain events must always be (re)playable. It should always be possible to replay your domain event. You obtain this by having it played immediately after you have completed your command. Then save the event to the db(stream).
23. © ZF Friedrichshafen AG Example in db(stream) 2024-06-20 | SCALAR Community of Practice for Devs 23
24. © ZF Friedrichshafen AG Where to begin? 2024-06-20 | SCALAR Community of Practice for Devs 24
25. © ZF Friedrichshafen AG Event Storming 2024-06-20 | SCALAR Community of Practice for Devs 25 To explore your domain.
26. © ZF Friedrichshafen AG Event Storming 2024-06-20 | SCALAR Community of Practice for Devs 26 Because your events have yet to be determined and discovered.
27. © ZF Friedrichshafen AG Event Storming 2024-06-20 | SCALAR Community of Practice for Devs 27 Determine your aggregate. => your root object within your bounded context
28. © ZF Friedrichshafen AG Event Storming 2024-06-20 | SCALAR Community of Practice for Devs 28 Bridge between your developers and stakeholders. Share the same knowledge and language. Different stakeholders also have different needs and insights. =>This can result into different bounded contexts.
29. © ZF Friedrichshafen AG Event Storming 2024-06-20 | SCALAR Community of Practice for Devs 29 To better understand your domain. This way you gain insights into the processes and phases of your application
30. © ZF Friedrichshafen AG Event Storming 2024-06-20 | SCALAR Community of Practice for Devs 30 Process
31. © ZF Friedrichshafen AG Event Storming 2024-06-20 | SCALAR Community of Practice for Devs 31 • Is about interactions with the users/business. • Domain Exploration. • Using the language of the business. • Interactions over time. • System transformations. • You cannot pay before you have ordered.
32. © ZF Friedrichshafen AG Example 2024-06-20 | SCALAR Community of Practice for Devs 32
33. © ZF Friedrichshafen AG Event Storming 2024-06-20 | SCALAR Community of Practice for Devs 33 • Remains a continuous process with every change. • It keeps improving your process from your model.
34. © ZF Friedrichshafen AG Event Storming 2024-06-20 | SCALAR Community of Practice for Devs 34 • Set up the space • Prepare a large wall or online board, sticky notes, and markers. • Collect domain events • Let participants write and place events (past tense) on the timeline. • Organize and group • Remove duplicates, sequence events, and group them by flow or theme. • Add supporting elements • Use colored notes for commands (blue), actors/systems (yellow), and views (green). • Explore and refine • Identify issues, gaps, and possible bounded contexts through discussion.
35. © ZF Friedrichshafen AG Event Storming 2024-06-20 | SCALAR Community of Practice for Devs 35 Let your code also reflect your model. Use the same names and format. This makes it easier to see the whole.
36. © ZF Friedrichshafen AG Constructors and Commands 2024-06-20 | SCALAR Community of Practice for Devs 36
37. © ZF Friedrichshafen AG Events 2024-06-20 | SCALAR Community of Practice for Devs 37
38. © ZF Friedrichshafen AG Handlers 2024-06-20 | SCALAR Community of Practice for Devs 38
39. © ZF Friedrichshafen AG At Work? 2024-06-20 | SCALAR Community of Practice for Devs 39 For each command, the aggregate gets in the correct state by loading all events from the current stream. Then execute your commands and add your events to the current stream.
40. © ZF Friedrichshafen AG Testing? 2024-06-20 | SCALAR Community of Practice for Devs 40
41. © ZF Friedrichshafen AG Testing? 2024-06-20 | SCALAR Community of Practice for Devs 41
42. © ZF Friedrichshafen AG When to use Event Sourcing? 2024-06-20 | SCALAR Community of Practice for Devs 42
43. © ZF Friedrichshafen AG When to use Event Sourcing? 2024-06-20 | SCALAR Community of Practice for Devs 43 If you have many complex transitions and interactions.
44. © ZF Friedrichshafen AG When to use Event Sourcing? 2024-06-20 | SCALAR Community of Practice for Devs 44 If you need audits. Or must be able to prove how you arrived at a state.
45. © ZF Friedrichshafen AG When to use Event Sourcing? 2024-06-20 | SCALAR Community of Practice for Devs 45 If you want to be able to debug what happened in production.
46. © ZF Friedrichshafen AG When to use Event Sourcing? 2024-06-20 | SCALAR Community of Practice for Devs 46 If you need time in your model. => For example: if first a and then c happens then x does something. If first b and then a happens then x is not allowed or does something completely different.
47. © ZF Friedrichshafen AG Pro and contra 2024-06-20 | SCALAR Community of Practice for Devs 47 • To have time in your system • To query over time • To move your complexity in the aggregates • When mastered, your system becomes modular • It requires a lot of discipline from the team. • Your system becomes more complex • Your system feels less familiar
48. © ZF Friedrichshafen AG Select * from Tables where firstOrder != appetizer and … 2024-06-20 | SCALAR Community of Practice for Devs 48
49. © ZF Friedrichshafen AG Command Query Responsibility Segregation 2024-06-20 | SCALAR Community of Practice for Devs 49
50. © ZF Friedrichshafen AG CQRS 2024-06-20 | SCALAR Community of Practice for Devs 50 Commands
51. © ZF Friedrichshafen AG CQRS 2024-06-20 | SCALAR Community of Practice for Devs 51
52. © ZF Friedrichshafen AG CQRS 2024-06-20 | SCALAR Community of Practice for Devs 52 Projector
53. © ZF Friedrichshafen AG CQRS 2024-06-20 | SCALAR Community of Practice for Devs 53
54. © ZF Friedrichshafen AG CQRS 2024-06-20 | SCALAR Community of Practice for Devs 54 Query
55. © ZF Friedrichshafen AG CQRS 2024-06-20 | SCALAR Community of Practice for Devs 55
56. © ZF Friedrichshafen AG CQRS 2024-06-20 | SCALAR Community of Practice for Devs 56 Where to use a read model? Everything you need to visualize • A list • A detail e.g. all reserved tables • Everything that is processed in the kitchen • What are the three most common orders • What is the average price per minute and what are the top 5 orders
57. © ZF Friedrichshafen AG CQRS 2024-06-20 | SCALAR Community of Practice for Devs 57 Every domain event that is needed for your read model is translated into a public event
58. © ZF Friedrichshafen AG CQRS 2024-06-20 | SCALAR Community of Practice for Devs 58 Corresponding records are retrieved adjusted and stored in the DB
59. © ZF Friedrichshafen AG CQRS 2024-06-20 | SCALAR Community of Practice for Devs 59 Events should no longer be ordered. 1. If you received a debit of €100 for a credit card once. 2. You can't find the credit card number. 3. Then just create it with an amount of €0. 4. Debit the card for €100, where it turns negative. 5. If then you create comes in for €200. then it will end at €100.
60. © ZF Friedrichshafen AG CQRS 2024-06-20 | SCALAR Community of Practice for Devs 60 Advantage? • To deploy your read and write db separately. • Scale separately. ➢ Filing taxes at the last minute will cause much less inconvenience. • If there are many transactions, your read db will catch up slowly. But it doesn't block your command side. • To create a completely new read model and feed it with all historical event. ➢ New report contains all historical data after processing.
61. © ZF Friedrichshafen AG Those same public events can also be sent to other services. There they are processed by policies. 2024-06-20 | SCALAR Community of Practice for Devs 61
62. © ZF Friedrichshafen AG Code @ https://github.com/kimVanRenterghemNew/EventSourcingAndCQRS 2024-06-20 | SCALAR Community of Practice for Devs 62
63. © ZF Friedrichshafen AG Demo 2024-06-20 | SCALAR Community of Practice for Devs 63
64. © ZF Friedrichshafen AG Questions? 2024-06-20 | SCALAR Community of Practice for Devs 64