イベントソーシング
現在の状態だけを保存する代わりに、すべての変更を不変のイベント列として保存するパターン。状態はイベントを再生して導き出す。完全な履歴、監査、「タイムトラベル」が手に入る。
考え方:UPDATE account SET balance = 100 とする代わりに、「50入金」「20出金」といったイベントを保存し、残高はその合計とする。利点は、完全な監査履歴が自然に手に入ること、任意の時点の状態を再現できること、ログを再生して後から新しいビューを作れることだ。CQRS(読み取りと書き込みのモデルを分ける)や「プロジェクション」(イベントストリームのマテリアライズドビュー)と組み合わせるのが一般的である。代償は複雑さで、過去のイベントのスキーマ進化、性能のためのスナップショット、書き込み側と読み取り側の結果整合性が課題になる。向いているのは金融やEコマースなど、「なぜそうなったか」と履歴が重要な領域(DDD)だ。ツールは EventStoreDB、ログとしての Kafka など。追記専用ログや台帳データベースとも関連する。