ADR-004: Без Event Sourcing и replay

Status: Accepted · Date: 2026-07-03

Контекст

Нужна история изменений: кто, что, когда изменил, возможность отката. Обсуждались варианты вплоть до реконструкции состояния на произвольную прошлую ревизию через воспроизведение лога изменений (replay).

Решение

Источник истины — нормализованное текущее состояние в PostgreSQL. История — audit_log с payload-diff: наблюдательный артефакт, полнота которого не является условием корректности системы. Откат — новое изменение по diff. Доменные события — синхронное внутрипроцессное соглашение кода (Структура backend), не персистентный лог.

Отклонённые альтернативы

Replay-реконструкция («ревизия — ссылка на изменения, состояние воспроизводится»). Чтобы replay был корректен, лог обязан стать истиной: каждый write-путь всегда пишет полное событие, формат событий становится вечным API, миграции обязаны понимать исторические события, потеря одной записи ломает воспроизведение молча. Это Event Sourcing со всей его ценой — изменением модели разработки всей системы, а не CPU-затратами.

Снапшоты состояния на каждую ревизию — второй источник истины рядом с нормализованной моделью; ревизии инкрементируются при каждом изменении, объём неограничен.

Последствия

• (+) Полнота audit_log желательна, но не критична: баг в аудите — потерянная запись журнала, а не неверное состояние системы.
• (+) Критерий физического разделения audit/revision зафиксирован в схеме БД — разделение по условию, а не по обсуждению.
• (−) «Состояние на произвольную прошлую ревизию» недоступно. Если появится конкретная задача «что работало на ноде в ревизии N» — решается сохранением отрендеренного NodeConfig в момент применения (ограниченный объём, явный владелец и retention), новым ADR.