イベントソーシング：データベースに記憶が必要なとき

UPDATE文を実行するたびに、何かが消える。古い値 — さっきまでそこにあったもの — が消える。ほとんどのデータベースは忘れるように設計されている。すべてのUPDATEが以前のものを上書きし、すべてのDELETEが完全に削除し、アプリケーションには現在のスナップショットだけが残る。

これは自然だから受け入れている。でもシステムが別の質問に答える必要があったら？「現在の状態は何か？」ではなく「ここにどうやってたどり着いた？」

それがイベントソーシングが答える質問だ。

CRUDが失うもの

銀行口座を考えてみよう。CRUDモデルでは：

残高が$1,100だとわかる。それが入金だったのか、返金だったのか、修正だったのか、バグだったのかはわからない。履歴は消去された。

不正調査員が「この口座の過去30日のすべての取引を見せてください」と求めたとしよう。CRUDでは、別の監査ログが必要だ。そしてその監査ログは常に後付け — 取ってつけたもの、一貫性がなく、決して完全ではない。

イベントソーシングモデル

現在の状態を保存する代わりに、それを生成したイベントのシーケンスを保存する：

現在の状態は導出されるもので、保存されるものではない。イベントをリプレイすればいつでも取得できる。しかしCRUDでは決して答えられなかった質問にも答えられる：

• 2月5日時点の残高は？
• 1月に何回の入金があった？
• 最後の出金はいつ？
• 完全な監査証跡を見せて。

イベントログが真実の源泉だ。現在の状態は単なるキャッシュされた計算結果に過ぎない。

イベントソーシングが輝くとき

金融システム。 銀行、決済処理業者、トレーディングプラットフォーム。規制要件で完全な監査証跡が義務付けられることが多い。イベントソーシングならこれが無料で手に入る — 後付けではなく、アーキテクチャそのものだ。

共同編集。 Google Docsはドキュメントを保存していない — すべてのキーストローク、すべての削除、すべてのカーソル移動を保存している。ドキュメントはすべての操作をリプレイした結果だ。

ECの注文管理。 注文は単に「出荷済み」ではない。注文され、確認され、支払い承認され、ピッキングされ、梱包され、出荷され、そして部分的に返品されたかもしれない。各ステップがカスタマーサポート、分析、紛争解決に重要だ。

本番問題のデバッグ。 何かがうまくいかないとき、障害の時点までイベントをリプレイできる。システム状態のDVRのようなものだ。

誰も言わないトレードオフ

ストレージの成長

イベントは追記のみ。永遠に蓄積する。高トラフィックのシステムは1日に数百万のイベントを生成する。戦略が必要だ：

• スナップショット — 最初からリプレイしないよう定期的に計算された状態を保存
• アーカイブ — 古いイベントをコールドストレージに移動
• コンパクション — 場合によっては古いイベントをサマリーイベントに圧縮

結果整合性

イベントストアが真実の源泉なら、読み取りモデルはイベントから構築される必要がある。イベントの書き込みと読み取りモデルの更新の間に遅延がある。UIがミリ秒から数秒間古いデータを表示する可能性がある。

スキーマの進化

イベントは不変だ。遡ってイベントv1をイベントv2に変更できない。バージョニングとアップキャスト戦略が必要だ：

クエリの複雑さ

「先月$1,000以上を入金したすべてのユーザー」を問い合わせたい？CRUDならSQLクエリだ。イベントソーシングではプロジェクション — そのクエリパターン専用に構築された読み取りモデル — が必要だ。異なるユースケースのために複数のプロジェクションを維持することになるだろう。

CQRS：自然な相棒

イベントソーシングはほぼ必ずCQRS（コマンドクエリ責務分離） と組み合わせる：

• コマンド側 — ビジネスルールを検証し、イベントを追記
• クエリ側 — イベントから最適化された読み取りモデルを構築

書き込みモデルと読み取りモデルは異なるデータ構造で、それぞれの目的に最適化されている。イベントストアがそれらをつなぐ。

判断フレームワーク

イベントソーシングを使うとき：

• 監査証跡がビジネス要件で、あると嬉しいものではない
• 「ここにどうやってたどり着いた？」という質問に答える必要がある
• ドメインに複雑な状態遷移がある（注文、ワークフロー、金融取引）
• デバッグや分析のために履歴をリプレイする必要がある
• 同じデータの異なるビューを複数の読み取りモデルが必要とする

イベントソーシングを使わないとき：

• シンプルなCRUDで十分（ブログ、ユーザープロフィール、設定ページ）
• チームがイベント駆動システムを構築した経験がない
• 読み取りの結果整合性を許容できない
• ビジネスが過去のデータを必要としない
• 監査可能性よりも開発速度を最適化している

正直な見方

イベントソーシングは強力だが要求も高い。CRUDが文字通り解決できない問題 — 完全な監査証跡、時間的クエリ、リプレイベースのデバッグ — を解決する。しかしほとんどのアプリケーションが必要としない複雑さを追加する。

銀行システムを構築していてイベントソーシングを使っていないなら、おそらく監査ログを取ってつけて一貫性があることを祈っているだろう。ブログを構築していてイベントソーシングを使っているなら、自転車にジェットエンジンを搭載しているようなものだ。

ドメインを知れ。それに応じて選べ。

---

目的地だけでなく旅路を保存しろ — ただし旅路が重要な場合だけ。

— blanho