An event that lands in sales.Events today must still be readable by the Kladde in five years. In that time the code changes a hundred times, the event never. In this lesson you learn which changes to an event type are harmless, which make stored events unreadable, and how to make them anyway when you have to. The occasion is a real request: DealWon should carry its amount as Money, with a currency, instead of as a bare number.

At the end, the Kladde has golden example files of all stored formats in the test project. They are the contract between today's code and yesterday's data.

Stored events never change

With a table holding the latest state, a migration changes the data together with the code: new column, convert the old values, done. With events that doesn't work, for three reasons:

  • Events are facts. A DealWon from March says what happened in March. Whoever rewrites it falsifies the history that event sourcing is meant to preserve.
  • The table is only added to. The adapter writes only with INSERT, and in lesson 4.8.5 the Kladde's identity loses the right to UPDATE on sales.Events.
  • There are too many places. Events live in backups, in exports, soon as messages in other contexts (module 4.6). A migration doesn't reach all of them.

From this follows the rule of this lesson: the code adapts to the stored events, never the other way around.