Part 01 of 16 · Day 1 · domain event
A stored result without the story
Problem and experience
The calculator stores the result, not the story
It writes a row and responds. But once the application is submitted, a lot more starts happening around it.
Saving
- Frontend
- Calculator API
- DatabaseUPDATE overwrites the original value
Application submission
- Calculator
- Risk
- Approval
- Disbursementoffline
From practiceWhen did you last miss the history of a change, or get held up by a service you were just waiting on?
TakeawayThe cost is twofold: history disappears and the caller is coupled to every service in the chain.
What it means
Request/response: the caller sends a request and waits for the response. State is a single row that is overwritten on change.
Why we use it
It is the simplest model. Easy to debug and everyone knows it.
When it makes sense
For small systems and simple screens where we need neither history nor independent services.
Where it breaks
- After an UPDATE we don't know who changed the value or from what.
- One slow or offline service brings down the whole call, but the steps before it have already changed data (partial failure).
- A chain of synchronous calls multiplies both latency and the risk of outage.
Imagine
The adviser saves an income of CZK 85,000 and a moment later CZK 60,000. Only the last number remains in the database.
CRUD is not a mistake. It is a decision with consequences.
Principle, application and exercise
A value becomes an event
Instead of “income is 60,000” we record “income was changed to 60,000”. Other services find out and decide for themselves what to do.
The sender doesn't know the recipient
- Calculatorincome change
- EventIncomeChanged
- Broker
- Anyone who needs itRisk, projections, audit…
What changes
- Valueoverwritten
- Factin the past tense, with time and cause
Trade-offWe gain independent services and a trail of changes. We pay with delay (eventual consistency) and harder diagnostics.
TakeawayAn event is a fact that has happened. A command is a request for something to happen.
What it means
We name an event in the past tense and attach the data describing the change. The sender itself doesn't know who will react to it.
Why we use it
Services can change independently. A new service is added by subscribing to the event, without touching the sender.
When it makes sense
When one change triggers work in several places or when we need to know what happened.
Where it breaks
- An event that is really a hidden command (“DoX”).
- Expecting an immediate result: reactions arrive with a delay.
- Introducing events without knowing who will read them.
Imagine
The adviser changes the income. The IncomeChanged event is read by Risk and the projection, and each handles it in its own way.
We don't start with technology, but with changing how we talk about changes.
Training for your team
Would you like this training for your team?
We run the training on your code and your domain problem. We agree the scope, dates and format with you.
Discuss the training →