Part 15 of 16 · Day 2 · audit, personal data protection
History that is both valuable and risky
Problem and experience
Who did it, and who may read it?
Events contain incomes and personal data. History is valuable, but also a risk.
- Eventpersonal data, income
- Event storeimmutable, long-term
- Who reads?
- Who deletes?right to erasure
From practiceWhat could you trace about a single change a year back?
TakeawayThe longer and more completely we remember, the more we have to protect.
What it means
Domain history captures changes in the domain. Security deals with who may access the data, and operational lifetime with how long and how we keep it usable.
Why we use it
Memory is useful only when we can trust it and can maintain it.
When it makes sense
When designing events, before the first data is stored.
Where it breaks
- Storing more personal data in events than necessary.
- Dealing with retention only after an incident.
- Treating domain history as a security audit.
Imagine
An event contains the client's full name and income. Five years later it is still there and nobody knows who reads it.
It is not just about storing information, but about keeping it usable and protected over the long term.
Principle, application and exercise
Audit, data protection and recovery
Domain history is not the same as a security audit. We decide what to store, for how long, and how we will recover the system.
Domain audit
- Who changed it
- What it followed on from
- causationId
Security audit
- Reading sensitive data
- Denied access attempts
- Incidents
Operational lifetime
- Retention
- Encryption
- Event store backups
- Recovery (DR)
Trade-offImmutable history and the right to erasure meet. The solution is designing the data up front (encryption with a key that can be destroyed), not rewriting events. There is no lab exercise for this part yet.
TakeawayForgetting information and not having to reprocess it every time are two different decisions.
What it means
The domain audit answers who made a change and what it followed on from. The security log answers reads of sensitive data and denied access attempts. Recovery means we can rebuild the event store and views after an outage.
Why we use it
Each of these questions has different sources and different retention.
When it makes sense
When designing a system with financial or personal data.
Where it breaks
- A snapshot as a replacement for history.
- Retention set only after an incident.
- A recovery nobody has tried.
Imagine
The client objects that they entered the instalment differently. A correcting event records the facts and the view is rebuilt, without rewriting the past.
We do not want to pay the cost of memory by accident. We want to choose it ourselves.
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 →