アーキテクチャパターン

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

イベントソーシングイベントストア状態再現監査ログCQRSDDD

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

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

「今の残高」じゃなくて「入金・出金の全履歴」を保存しておいて、必要なとき足し算して状態を出すやり方。銀行の通帳みたいなイメージだね！

イベントソーシングとは

イベントソーシング（Event Sourcing）とは、システムの「現在の状態」ではなく、状態を変化させた「イベントの列」を正とするデータ管理パターンです。通常のDBが「最新の値」を保存するのに対し、イベントソーシングでは「〇〇が起きた」という事実だけを時系列順に記録し続け、現在の状態はそれらを積み重ねて計算します。

この方式の最大のメリットは完全な変更履歴が自動的に手に入ることです。「なぜ今の状態になったのか」を常に説明でき、過去の任意の時点の状態を再現できます。また、後から「あのイベントが発生したときにこのサービスにも通知したかった」というような新しい要件にも、保存済みのイベントを再生（リプレイ）することで対応できます。

仕組みと構造

データ保存の比較

方式	保存内容	例（注文キャンセルの場合）
通常のDB	最新状態のみ	`status = "cancelled"` で上書き
イベントソーシング	全イベントの列	`OrderPlaced`, `PaymentReceived`, `OrderCancelled` を追記

イベントストアの構造

イベントID | 集約ID | イベント種別          | 発生時刻            | データ(JSON)
---------- | ------ | -------------------- | ------------------- | -----------
1          | ord-1  | OrderPlaced          | 2024-01-10 10:00:00 | {items:[...]}
2          | ord-1  | PaymentReceived      | 2024-01-10 10:05:00 | {amount:5000}
3          | ord-1  | OrderShipped         | 2024-01-11 09:00:00 | {tracking:"..."}
4          | ord-1  | OrderCancelled       | 2024-01-11 10:00:00 | {reason:"..."}

スナップショット

イベントが大量に蓄積されると再生に時間がかかります。定期的にスナップショット（ある時点の状態）を保存し、最新のスナップショット以降のイベントだけを適用することで高速化します。

歴史と背景

イベントソーシングはDDD（Domain-Driven Design）コミュニティ、とくにGreg Youngによって2000年代後半に体系化されました。「なぜ今の状態になったか説明できないシステム」への問題意識が背景にあります。金融・会計の世界では「元帳に上書きしない」「仕訳の積み重ねが残高を作る」という考え方が古くからあり、イベントソーシングはこれをソフトウェアに持ち込んだとも言えます。AWSのDynamoDB StreamsやApache Kafkaの台頭により、大規模なイベントストアの実装が現実的になりました。