> Once you distinguish all events you’re fine with and want to migrate your relational data, don’t try to cheat; don’t put your events as small and granular. Relational data is flattened; if you try to retrofit what happened from the final state, you will likely fail or not be precise at best.
The article is aimed at people who already have relational data, and want to build an event-driven system (whose events will eventually end up as relational data again downstream.)
Your system A might look like:
| Name | Balance |
| Michael | $3.03 |
You might design your system B to have the events AmountCredited{name, amount} and AmountDebited{name, amount}.
You don't know how system A ended up at its current state. That's what's meant by "flattened". When you want to "migrate the relational data", i.e. convert system A's relations into events, it's tempting to use the obvious AmountCredited{"Michael", $3.03} because you know it will result in Michael having the correct balance in the final system.
But it's not good to reuse AmountCredited, _because no such event actually happened_, which is why it could be called "cheating". If future-you looks at historical data, $3.03 won't correspond to any real transaction that happened. Instead you should instead make a special event like AmountImported{name, amount}.
For this example the convention in accounting is to use 'balance brought forward'.
It's a real transaction that happened, and everyone knows what it means i.e. the previous ledger with this account was closed off and the new one has the balance that was there when th book was closed.
Using 'imported' describes what you did, but not what the intention was.
.. what?