Как я и говорил — запись в таблице или ее история может только подсказать природу изменений, особенно если код работает с ней через ORM. Event Sourcing дает больше, но и заплатить надо не мало.
В одной из систем, часть сущностей, были обычными таблицами и ORM к ним. В событиях мы тогда просто ссылались на эту сущность по ID, а в denormalizers вычитывали по этому ID, когда надо было.
Да, сам подход для решения задач не новый. Просто как-то с DDD и CQRS его подняли выше в архитектурный паттерн. CQRS — это тот же CQS только опять же выше по архитектуре.
В целом, я так понял Ваш алгоритм архивирования событий напоминает Snapshots в Event Sourcing. Разница в том, что у Вас были скорее всего таблицы с установленной схемой (поправьте если не так), а тут при хранения событий в БД — одна колонка «Event Data» (скажем в XML или JSON). В целом одно и тоже, однако с первым работать проще.
А доводилось видеть код еще и где denormalizers записывают отображения в NoSql (т.н. reads store)?
Но в целом да, подход не новый и сегодня он называется Event Sourcing. Однозначно хороший инструмент, если знать как и когда применить.
В целом, я так понял Ваш алгоритм архивирования событий напоминает Snapshots в Event Sourcing. Разница в том, что у Вас были скорее всего таблицы с установленной схемой (поправьте если не так), а тут при хранения событий в БД — одна колонка «Event Data» (скажем в XML или JSON). В целом одно и тоже, однако с первым работать проще.