イベントソーシングとCQRSの原理

状態ではなく「起きた事実」を保存する

通常のCRUDでは、テーブルの行が現在状態を保持し、更新は前の値を上書きします。balance = 1000 を balance = 700 に書き換えた瞬間、「いくら引かれたのか」「いつ誰が引いたのか」は失われます。イベントソーシングはこの上書きをやめ、状態を生んだ事実（イベント）の列そのものを永続化します。

口座の状態を、結果ではなく原因の列として持つ
  Opened(initial=0)
  Deposited(amount=1000)
  Withdrawn(amount=300)
→ 現在の balance はどこにも保存されていない。イベントを順に適用して導出する

イベントは過去に確定した事実なので不変（immutable）であり、追記専用（append-only）のログとして積まれます。重要なのは、ここでイベントが**唯一の真実の源（source of truth）**になることです。状態テーブルがあったとしても、それは派生物であって権威ではありません。

再生：左畳み込みで状態を再構築する

現在状態は、初期状態にイベントを順に適用した**畳み込み（fold）**の結果です。状態遷移関数を apply(state, event) とすると、現在状態は次式で定義されます。

state = fold(apply, initial_state, [e1, e2, ..., en])
      = apply(apply(... apply(initial, e1) ..., e(n-1)), en)

この性質から、イベントソーシングの強みが演繹的に出てきます。第一に、任意の過去時点の状態を、その時刻までのイベントだけ畳み込めば復元できる（タイムトラベル）。第二に、apply を新しく書けば過去のイベント列から新しいビューを後から作れる（後付けの分析・新機能）。第三に、イベント列がそのまま完全な監査証跡になる。CRUD では設計時に監査ログを仕込み忘れたら過去は取り戻せませんが、イベントソーシングでは履歴が構造的に保証されます。

apply には満たすべき制約があります。純粋関数であり、決定的でなければならないこと。同じイベント列を畳み込めば、いつ何度実行しても同じ状態になる必要があります。ここで apply の中で現在時刻を読む、乱数を引く、外部APIを叩く、といった非決定的な操作をすると、再生のたびに結果がぶれて真実が揺らぎます。非決定な値はイベント生成時に確定させてイベントへ焼き込み、apply はイベントが運んできた値を反映するだけにします。

CQRS：読み書きモデルを分離する

イベント列は「事実の追記」には最適ですが、「現在の全口座を残高順に並べる」のような問い合わせには絶望的に向きません。毎回すべてのイベントを畳み込む必要があるからです。ここでCQRS（Command Query Responsibility Segregation）が要請されます。コマンド側（書き込み）とクエリ側（読み取り）で別々のモデルを持つ設計です。

コマンド側: コマンド受理 → 不変条件を検証 → イベントを発行 → イベントストアへ追記
クエリ側  : イベントを購読 → 投影を更新 → 用途別の読み取りビューを提供

書き込み側はイベントストアという正規化された真実だけを扱い、読み取り側は用途ごとに非正規化したビューを複数持てます。一覧用、検索用、集計用を別々のストア（RDB、検索エンジン、KVS）に最適化して同居させられる——これがCQRSとイベントソーシングが相性良く語られる理由です。なお両者は独立した概念で、CQRS はイベントソーシングなしでも、その逆でも成立します。

投影（projection）：イベントからビューを作り続ける

投影は、イベントストリームを消費して読み取りビューへ反映する処理です。各投影は「どこまで読んだか」を示す**チェックポイント（読み取り位置）**を持ち、新着イベントを順に apply 相当の更新でビューへ畳み込みます。

投影が満たすべき最重要の性質はべき等性です。投影プロセスはクラッシュや再起動で、同じイベントを二度処理しうるからです（/devops/idempotency-exactly-once/ で扱う at-least-once の世界）。「カウンタに+1する」ような非べき等な更新を素朴に書くと、再処理で数が狂います。対策は二つです。

• イベントに単調増加の通し番号（グローバル順序またはストリーム内シーケンス）を振り、投影は処理済み番号以下を捨てる。重複を番号で弾く。
• ビュー更新自体をべき等にする（絶対値で上書き、UPSERT、集合への挿入など）。

再生可能性も投影の利点です。投影のバグを直したら、チェックポイントをゼロに戻して全イベントを流し直せばビューを作り直せます。新しい読み取りモデルが必要になったら、新しい投影を空から再生して構築する。イベントが真実である限り、ビューはいつでも捨てて再生成できる使い捨ての派生物になります。

スナップショット：再生コストを定数化する

集約（aggregate、ひとつの不変条件の境界＝口座など）のイベントが何万件にもなると、コマンドのたびに全イベントを畳み込むのは非現実的です。スナップショットは、ある時点までの畳み込み結果を保存しておく最適化です。

復元 = 直近スナップショット state@v
       + それ以降のイベント [e(v+1), ..., en] を畳み込む

これで再生コストは「スナップショット以降の差分」だけになり、おおむね定数時間に収まります。設計上の鉄則は、スナップショットはあくまでキャッシュであり、真実ではないことです。スナップショットを消してもイベント列から完全に再構築できなければなりません。だからスナップショットにはそれが対応するイベントのバージョン番号を必ず持たせ、apply のロジックを変えたら古いスナップショットは破棄して作り直せるようにします。スナップショットを権威にすると、上書き型CRUDの問題がそのまま戻ってきます。

イベントの版管理：不変な事実を進化させる

最大の運用上の難所がバージョニング（スキーマ進化）です。イベントは不変なので、過去に書かれたイベントの形を後から変えることはできません。しかしビジネスは変わり、イベントに項目を足したい・名前を変えたい・分割したいが必ず起きます。古い形式のイベントは永久にストアに残り続け、apply も投影も全バージョンを解釈できなければならない——これが上書き型DBのマイグレーションと根本的に違う点です。

実務で使われる手法を整理します。

• 後方互換な追加（弱いスキーマ）：項目の追加はデフォルト値で吸収する。最も安全で第一選択。
• アップキャスティング（upcasting）：古いイベントを読み出す瞬間に、新しい形へ変換する関数を通す。ストア上の生イベントは不変のまま、メモリ上で最新版に揃える。
• 新イベント型の併存：OrderPlacedV2 を新設し、apply は V1 と V2 の両方を処理する。意味が変わる変更で使う。
• イベントの書き換え（コピー＆変換）：全イベントを新ストリームへ変換コピーする最終手段。監査証跡の連続性が切れるため慎重に。

イベントの順序保証も論点です。多くの実装は集約（ストリーム）単位では厳密順序を保証しますが、集約をまたいだグローバル順序は保証しないか、保証すると書き込みのスケールが制約されます。集約間の因果を扱うときは、論理時刻（/devops/logical-clocks/）で順序を補い、複数集約にまたがる更新はサーガ（補償トランザクション）で結果整合に組むのが定石です。マイクロサービス間でイベントを連携する設計判断は /devops/microservices/ とも地続きです。

まとめ

• イベントソーシングは不変なイベント列を唯一の真実とし、状態は fold(apply, initial, events) の再生で導出する。過去の任意時点の状態と完全な監査証跡が原理的に得られる。
• 再生が成り立つ条件は apply が決定的な純粋関数であること。非決定な値はイベント生成時に焼き込み、再生でぶれないようにする。
• CQRS は書き込み（コマンド→イベント）と読み取り（投影ビュー）を分離する。両者は非同期同期のため結果整合になり、読み取りラグを前提に設計する。
• 投影はべき等かつ再生可能で、ビューは使い捨ての派生物。スナップショットは再生コストを定数化するキャッシュであり、真実にしてはならない。
• バージョニングは不変イベントとスキーマ進化を両立させる難所で、後方互換な追加・アップキャスティング・新イベント型併存を使い分ける。古いイベントは全バージョン解釈し続ける必要がある。