アーキテクチャパターン

イベントソーシングいべんとそーしんぐ

イベント状態管理CQRSドメイン駆動設計イベントストア監査ログ

イベントソーシングについて教えて

簡単に言うとこんな感じ！

銀行の通帳みたいなイメージだよ！「残高は1万円」って今の状態だけ記録するんじゃなくて、「入金3万・出金2万・出金1万」って出来事を全部記録しておくことで、いつでも残高を計算できる仕組みなんだ！

イベントソーシングとは

イベントソーシング（Event Sourcing）とは、システムの「現在の状態」ではなく、「状態を変化させた出来事（イベント）の履歴」をデータとして保存するアーキテクチャパターンです。たとえば「在庫が5個」という結果だけ保存するのではなく、「入荷10個」「出荷3個」「出荷2個」という出来事を順番に積み上げておき、現在の状態はそこから計算して導き出します。

このアプローチの最大の強みは、すべての変更履歴が完全に残ることです。いつ・何が起きたかを正確に追跡できるため、「あの時点での状態に戻したい」「なぜこの状態になったか知りたい」という要求に対して、データを消さず・書き換えずに答えられます。従来のデータベース設計（現在値を上書き保存するやり方）では失われてしまう「変化の過程」を保持できる点が画期的です。

もともとはドメイン駆動設計（DDD） のコミュニティで広まった考え方で、特に業務上「なぜその状態になったか」の説明責任が求められる金融・EC・物流などの領域で採用されています。後述する CQRS（コマンドクエリ責務分離） と組み合わせて使われることが多いパターンです。

イベントソーシングの仕組み

通常のDB設計との比較

比較軸	通常の設計（状態保存）	イベントソーシング（出来事保存）
保存するもの	現在の状態（最新値）	起きた出来事の列（イベントログ）
現在の状態	DBにある値をそのまま使う	イベントを再生して計算する
過去の状態	基本的に参照不可	イベントを途中まで再生すれば復元可能
変更履歴	別途ログを設計しないと残らない	構造上、全履歴が自動的に残る
複雑さ	シンプル	やや高い（設計・運用コストあり）

イベントの流れ（基本構造）

ユーザー操作
    ↓
コマンド（"注文を確定せよ"）
    ↓
ドメインロジック（バリデーション）
    ↓
イベント生成（"注文が確定された" OrderConfirmed）
    ↓
イベントストア（追記専用DBに保存）
    ↓
リードモデル更新（画面表示用のデータを再計算）

覚え方・語呂合わせ

「結果じゃなくて出来事を貯める」 ＝通帳式DB

銀行の通帳は「残高：10万円」とだけ書かれているのではなく、入出金の履歴がずらっと並んでいますよね。イベントソーシングはまさにこの通帳方式です。現在の残高（状態）は、全行を足し引きして計算します。

イベントの例（ECサイトの注文）

イベント名	内容	タイムスタンプ
`OrderPlaced`	注文が作成された	10:00:01
`PaymentReceived`	決済が完了した	10:00:45
`ItemShipped`	商品が出荷された	翌日 09:30:12
`OrderDelivered`	配達が完了した	翌々日 14:22:05

この列を再生すると「注文の現在状態＝配達済み」が計算できます。途中の PaymentReceived まで再生すれば「決済完了後・出荷前の状態」も復元できます。

歴史と背景

2000年代初頭 — エリック・エヴァンスが著書『ドメイン駆動設計（DDD）』でイベントを中心にした設計思想を整理。イベントソーシングの概念的な土台が形成される
2005年頃 — マーティン・ファウラーがイベントソーシングパターンを整理・命名し、ブログ記事で広く紹介。エンタープライズ設計パターンとして認知され始める
2010年代前半 — グレッグ・ヤングがCQRSとイベントソーシングをセットで体系化。専用のイベントストア実装（EventStoreDB）をオープンソースで公開
2010年代後半 — マイクロサービスアーキテクチャの普及とともに再注目。サービス間の非同期連携手段としてイベントが重要視される
2020年代 — Apache Kafka・AWS EventBridgeなどのイベントストリーム基盤が整備され、クラウドネイティブな文脈でも広く使われるようになる

CQRSとの組み合わせ

イベントソーシングは単独でも使えますが、CQRS（Command Query Responsibility Segregation：コマンドクエリ責務分離） と組み合わせると真価を発揮します。CQRSとは「データを書き込む操作（コマンド）」と「データを読み取る操作（クエリ）」を別々のモデルで扱う設計パターンです。

イベントソーシングのメリット・デメリット

観点	メリット	デメリット
履歴管理	全変更履歴が自動で残る	ストレージ使用量が増える
状態復元	任意の時点の状態を再現できる	現在状態の取得に計算コストがかかる
デバッグ	「なぜこうなったか」が追いやすい	システム設計の複雑さが増す
スケール	読み書きを独立してスケールできる	チームへの学習コストが高い
整合性	イベントは事実なので書き換えられない	スキーマ変更（イベントの後方互換）が難しい

実務での使いどころ

イベントソーシングが特に有効なのは、以下のような場面です。

金融・会計システム — 帳簿は上書きではなく仕訳の積み上げ。法的な監査要件にも対応しやすい
ECサイトの注文管理 — 注文ステータスの変化を追跡し、カスタマーサポートが経緯を確認できる
在庫管理 — 入荷・出荷・返品の積み上げで在庫数を管理。数が合わないときに原因を追える
コラボレーションツール — ドキュメントの編集履歴（Google Docsの変更履歴のような機能）
マイクロサービス間の連携 — サービスをまたいだトランザクション管理にイベントを使う

一方で、CRUD（単純な作成・読取・更新・削除）で十分なシステムや、少人数のシンプルなシステムに無理に導入すると、設計の複雑さだけが増して逆効果になります。「本当にこのシステムに必要か」を慎重に判断することが重要です。