Another difficult topic is how to change events. We began to understand the domain domain better, the definition of the event has changed. What should I do in the program?
Many presentations say that events are facts, and they are unchangeable. I would formulate that events are history. And it is clarified (if we have learned more about the fact) or cleaned up (for example, a legal requirement).
Event changes can be divided into 4 types:
- Business clarification is better done as a separate corrective event.
- Technical change (for example, the same address, but now stored in a new way in 10 fields instead of one) – it makes sense to do data migrations in order not to support multiple versions of the event for a long time. For intermediate states, there is a version field in the storage structure.
- Legal purges - I would make a special code in this regard, which would change the recorded events as required. This is a complete “violation” of the principles of event sourcing, but the law is above these principles.
- Technical cleaning - when the data is simply no longer needed. This is especially true for SAAS providers. It is done by some kind of periodic work.