Slide 1

Slide 1 text

Event Sourcing Why state is not a fact but a first class derivative of things that happened

Slide 2

Slide 2 text

Who am I Frank Jogeleit @move:elevator GmbH Backend Engineer GitHub: https://github.com/fjogeleit Twitter: @FrankJogeleit

Slide 3

Slide 3 text

Do you think your bank account balance is a column in a table?

Slide 4

Slide 4 text

What is Event Sourcing? • Its used for • most financial systems like Banking-, Trading-, Gambling Software • healthcare like medical files • legal contracts For sure nothing new

Slide 5

Slide 5 text

What is Event Sourcing • Proper Audit • Logging core idea

Slide 6

Slide 6 text

„Event Sourcing says all state is transient and you only store facts“

Slide 7

Slide 7 text

What is Event Sourcing? Traditional View Line Items (2) Purchase Order Shipping Informations

Slide 8

Slide 8 text

What is Event Sourcing? Event Sourcing View Card created 3 Items Added Item Removed Shipping Information Added Event Stream

Slide 9

Slide 9 text

What is Event Sourcing? • Losing no Information • Explicit Time Information • No updates / deletes, only append • Who now which data will be valuable in the future? • State is a first class derivative What changes?

Slide 10

Slide 10 text

What is Event Sourcing? • Past Data for future features • Reports • Events are use cases • Code reflect behavior • Recreate state at any point in time in the past New capabilities

Slide 11

Slide 11 text

What is Event Sourcing? • Readmodels are a (persistent) representation of the current state of your application • Created as a left fold of your Event Stream in historical order • You can create as many Readmodels as you want for a single Event Stream • Readmodel persistence is independent from your Events, e.g. • InMemory for business decisions • Redis for short caches • SQL or NoSQL Databases for Views Readmodels

Slide 12

Slide 12 text

CQRS Command Query Responsibility Separation

Slide 13

Slide 13 text

What is CQRS? • Like the name already implies this pattern separate reading from writing operations • Your operation has return type void? -> Command • Your operation returns any value? -> Query • Queries must not change any state of your app • When you execute a query many times, the result has to be the same. (Assumed no other operations happened) Not much more as simple Pattern

Slide 14

Slide 14 text

CQRS + Event Sourcing • Commands represent behavior and create one or many Events • The EventStore is the single source of truth • ReadModels could be used for business decisions(*) • Queries using Readmodels to return application state How they work together

Slide 15

Slide 15 text

Side Effects • It many cases some kind of MessageBuses are used to implement the CQRS pattern • Beside a Command- and QueryBus you can use an EventBus to trigger some kind of Side Effect • An EventBus publish persisted (Domain) Events, so you can listen for it and execute related logic, for example • send a Registration E-Mail • trigger another related service to your event (Purchase- and Billing Service) EventBus / ProcessManager / Saga - you named it

Slide 16

Slide 16 text

Trade Offs • Replaying many Events (really many) is time expensive, you can create snapshot but you also have to manage them • Creating Readmodels asynchronously can lead to concurrency problems • Events are immutable but in some cases like GDPR (DSVO) you have to anonymize Data • Event Sourcing with Files need additional work Event Sourcing is perfect, isn’t it? - Almost

Slide 17

Slide 17 text

Bank Account API Event Sourcing by Example

Slide 18

Slide 18 text

Event Sourcing by Example • Github: https://github.com/fjogeleit/event-sourcing-nodejs-example • NodeJS API Example with TypeScript, NestJS • Hosted Example http://event-sourcing-example.webdev-jogeleit.de/ • EventStore https://github.com/fjogeleit/event-store Bank Account API

Slide 19

Slide 19 text

Questions?