Еще одна сложная тема – как менять события. Мы стали лучше понимать доменную область, определение события изменилось. Что делать в программе?

Во многих презентациях говорят, что события – это факты, а они неизменны. Я бы формулировал, что события – это история. А она уточняется (если мы больше узнали о факте) или вычищается (например, юридическое требование).

Можно разделить изменения событий на 4 типа:

  • Бизнес-уточнение – лучше делать отдельным корректирующим событием.
  • Техническое изменение (например, тот же адрес, но теперь хранится по-новому в 10 полях вместо одного) – имеет смысл делать миграции данных, чтобы долго не поддерживать множество версий события. Для промежуточных состояний в структуре хранения есть поле версии.
  • Юридические чистки – делал бы специальный код на этот счет, который как требуется менял бы записанные события. Это полное “нарушение” принципов event sourcing, но закон выше этих принципов.
  • Технические чистки – когда данные уже просто не нужны. Особенно это актуально для SAAS-провайдеров. Делается какой-то периодической работой.