状態そのものではなく「状態を変化させたイベントの列」を真実として永続化し、現在の状態は再生で復元する設計パターン。Greg Young らが DDD コミュニティで広めた。
概要
通常の DB は「現在の在庫数: 12」を保存する。イベントソーシングは「入荷+10」「出荷-3」「入荷+5」というイベント列を保存し、必要なときに畳み込んで「12」を導出する。 過去の事実を上書きせず追記のみ で扱うのが核心。
通常の永続化との違い
| 観点 | 状態保存（CRUD） | イベントソーシング |
|---|---|---|
| 保存する真実 | 現在の状態 | 状態変化のイベント列 |
| 過去の参照 | 別途監査ログが必要 | イベント列がそのまま履歴 |
| 状態の再構築 | 不要 | イベントを畳み込む |
| 書き込みモデル | UPDATE 中心 | APPEND-ONLY |
| 「もし◯◯だったら」の分析 | 困難 | イベントを再生して試算可能 |
代表的な利点
- 完全な監査証跡 — いつ・誰が・何をしたかを欠落なく追える
- 時間軸での再現 — 任意の過去時点の状態を復元できる
- 因果関係の可視化 — ドメインで起きた出来事をそのまま残せる
- 読み取りモデルの自由設計 — 同じイベントから複数の Read Model を生成できる
注意点
| リスク | 対策 |
|---|---|
| イベントスキーマの変更 | バージョン付与・アップキャスト戦略を最初から設計 |
| 再生コスト増大 | スナップショットを定期的に保存 |
| 学習コスト | 既存 CRUD 文化との認識ギャップが大きい |
| 削除要求（GDPR 等） | 暗号化キー破棄など crypto-shredding で対応 |
イベント DB（Event Store）の選び方
イベントソーシングを実装する際に、イベント列を格納するストレージを Event Store（イベント DB） と呼ぶ。専用 DB を使うか、汎用 DB の上に構築するかで選択肢が分かれる。
| 分類 | 代表例 | 特徴 |
|---|---|---|
| 専用 Event Store | EventStoreDB（現 Kurrent） | ストリーム・サブスクリプション・Projection を一級機能として提供 |
| RDBMS 上のライブラリ | Marten（PostgreSQL / .NET）・Axon Server（Java）・Eventuate | 既存の PostgreSQL / SQL 資産を活かせる。運用の学習コスト低 |
| ドキュメント DB | MongoDB + 自作追記テーブル | 柔軟だが、Projection / 楽観ロック等は自力で作り込む必要がある |
| メッセージングログ | Apache Kafka・Apache Pulsar | ログ無期限保持で Event Store として使える。分散前提の大規模系 |
| クラウドマネージド | AWS DynamoDB + Streams + Kinesis / Azure Cosmos DB（Change Feed） | マネージドでスケールアウト容易。ベンダーロックインに注意 |
選定観点
| 観点 | チェックポイント |
|---|---|
| 書き込み原子性 | 1 集約 = 1 ストリームで楽観ロックが効くか |
| 読み取り（再生）性能 | 長いストリームでスナップショットや Projection を作れるか |
| スキーマ進化 | アップキャスト・バージョン付与のサポート |
| Subscription / Projection | イベントを購読して Read Model を自動更新できるか |
| マルチテナント | テナントごとにストリーム・パーティションを分けられるか |
| 既存運用との親和性 | RDBMS 運用の知見をそのまま使えるか |
| 言語・ランタイム | .NET / Java / Node.js での実装サポート |
よくある誤選定
- 「Event Store = Kafka」と短絡 — Kafka はメッセージングのログで、細粒度の楽観ロックや任意ストリーム再生には向かない。集約 1 件を再生するのに全体を走査する設計になりがち
- 「RDBMS で自作する」 — 単純な append は簡単だが、スナップショット・Projection・並行制御・再生ツールなど運用周りで疲弊する。ライブラリ採用を先に検討
- 「イベント DB を唯一の SSoT にする」 — Read Model を作らず直接イベントから UI を組み立てると、画面表示のために巨大ストリームを毎回再生して破綻する
CQRS との組み合わせ
CQRSの書き込み側でイベントソーシングを採用するのが定番。書き込みはイベント追記で原子性を保ち、読み取りはイベントを購読した Read Model から行う。EC のように「在庫変動」「注文確定」「キャンセル」など出来事の追跡が業務価値に直結する領域と相性が良い。
EC ドメインでの適用イメージ
CTS-EC 共通商品マスタのように マルチモール在庫・出品状態の同期 が業務の中心になるドメインでは、状態スナップショットだけでは「いつ・なぜ在庫差分が出たのか」「どの操作でモール反映が崩れたのか」を後追いしにくい。出来事を追記して残し、必要に応じて再生する設計は監査性とトラブル復旧の両面で効きやすい。
関連記事
- 開発手法ガイド：概要 — DDD 発展形としての位置づけ
- CTS-EC 共通商品マスタ — 出来事の追跡が業務価値に直結する EC ドメインの実例