ここでは、イベントソーシングについて次の観点で説明します。
イベントソーシングとは
イベントソーシング（Event Sourcing）とは、、「誰が・いつ・何を・なぜ したか」というイベントをデータの“唯一の情報源（source of truth）”として保存・管理することです。
なので、イベントは 「事実の記録」 として更新や削除できず不変（immutable）です。
通常のシステムでは、現在の状態（たとえば契約の最新情報）をRDBなどに「最新値」として保存します。
しかし、イベントソーシングでは、「状態がどう変化してきたか（イベント）」を時系列で保存するので、必要に応じて特定の時点の状態を再構築（再現）することができます。
つまり、通常のDBが記録するのが「結果」であれば、イベとソーシングはその「原因」を記録するのです。
なので、次のような要求がある場合、状態の記録だけでなく、イベントソーシングを検討します。
- 監査とコンプライアンス
金融業界や医療業界など、厳格な規制が存在する分野では、データの変更履歴をすべて追跡・保存する必要があります。
監査の際に、ある取引や医療記録がどのように変更され、誰がいつそれを行ったのかを正確に再現することができます。
例えば、ある口座の残高が特定の日時にどのように変更されたのかを確認し、その正当性を証明するために過去の状態を再現できます。 - デバッグとエラー解析
ある問題が発生した時点のシステム状態を再現することで、どのイベントが原因でエラーが発生したのかを突き止めることができます。
例えば、特定の顧客の注文がなぜ誤処理されたのかを再現し、エラーの原因を特定するために、当時のイベントシーケンスを確認します。 - ビジネスプロセスの検証・分析
ある注文がどの時点で承認され、どのタイミングで出荷指示が出され、その後どのように顧客に届いたか、という一連のプロセスをイベントを使って再現することで、業務フローを振り返り改善点を見つけることができます。 - ユーザートラッキングと行動解析
ユーザーがどのような操作を行った結果、特定の商品をカートに入れ、購入を完了したのかというユーザーの操作履歴を再現し行動を解析をすることができます。 - 予測モデルの精度向上
予測モデルを訓練するために、特定の時間範囲のデータが必要な場合があります。
イベントソーシングではその期間内の状態遷移を正確に再現できるためより精度の高い予測モデルを構築することができます。
イベントソーシングの実現方法
イベントソーシングを実現するときは、コマンド・クエリ責務分離（CQRS）パターン
とイベント駆動アーキテクチャ（Event-Driven Architecture: EDA：システム内のコンポーネント同士が「イベント」を使って非同期に連携・通信するアーキテクチャスタイル）を使います。
CQRSのコマンド処理にイベントソーシングを適用し原因をイベントストアに記録するとともに、クエリ処理に通常の状態管理を適用し結果をデータストアに記録します。
具体的には次のようなプロセスでイベントと状態を管理します。
- イベントの発生
コマンドを受け取ると、状態を変更するのではなく、イベントを生成し、イベントストアに記録する。 - 状態の更新
イベントが記録されたら、非同期メッセージングで状態管理（クエリ処理側）にイベントを渡し、状態管理は、そのイベントに基づいてデータストアを更新する。
例えば、「注文登録イベント」が発生したら、そのイベントに基づいて「注文の最新状態」をデータストアに書き込む。 - クエリの処理
最新の状態を取得する場合は、データストアを参照する。
高頻度なクエリ処理はデータストアにオフロードし、イベントストアの負荷を減らす。 - 状態の再構築
必要に応じて、データストアのデータが壊れた場合やリプレイ（再現）が必要な場合は、イベントストアのイベントから最新の状態を復元する。
ヴォーン・ヴァーノンの実践ドメイン駆動設計という書籍では、ドメイン駆動設計（DDD）の構成要素である集約ごとにイベントストアを設け、イベントソーシングを実現することを推奨しています。
また、Sam Newmanのマイクロサービスアーキテクチャという書籍では、DDDの集約ごとにマイクロサービスを設けることにより、マイクロサービスの一貫性を保ちやすく、依存関係を最小限にできると説明しています。
集約は、ドメインオブジェクトのライフサイクルを管理する単位であるので、この単位にコマンド処理のマイクロサービスを設け、イベントソーシングによって集約のイベントを管理することで、過去の証跡が追跡可能なシステムを構築することができます。
次の図のように各マイクロサービスがイベント駆動で自律的にトランザクションを管理するSagaにイベントソーシングを組み込むことも可能です。
イベントソーシングの例
最後に、DBの現在の状態に至る過程（イベント）の履歴を持たせる必要がある業務の例を紹介します。
監査証跡（Audit Trail）が必要な業務
監査証跡を確保することで、不正防止・法令遵守（コンプライアンス）・データ改ざん防止を実現することができます。
特徴
- 過去にどのような変更が行われたのかを正確に再現できる必要がある。
- 誰が・いつ・何を・どのように変更したのかを記録する必要がある。
- 法規制・コンプライアンスの要件を満たす必要がある。
業務例
- 金融・銀行業務
口座の取引履歴（入出金、送金、手数料の発生など）
投資商品の売買履歴
ローンの支払いや残高の変動 - 医療・ヘルスケア業務
患者の診療記録の変更履歴（診断内容、投薬変更など）
医療機器の使用履歴（いつ・どの患者に使用されたか） - 政府・法務・公共機関
許認可の申請と審査プロセスの履歴
裁判記録や判決の履歴
税務申告・修正履歴 - ERP（企業資源計画）
発注、支払い、在庫の変更履歴
予算管理や会計データの変更履歴
長期間の履歴を活用した分析が必要な業務
過去のデータを分析することで、将来のトレンド予測・改善施策の立案・異常検知が可能になります。
特徴
- 過去のデータの変化を分析する必要がある（単なる最新の状態では不十分）。
- 業務の改善や予測モデルに、過去の変更データが役立つ。
業務例
- マーケティング・顧客行動分析
ECサイトのカート履歴や購入履歴の変化
ユーザーのアクセス履歴、ページ滞在時間、クリック履歴 - IoT・センサー管理
温度や湿度の変動履歴（工場や物流の品質管理）
スマートメーターの電力使用履歴 - SCM（サプライチェーン・マネジメント）
商品の物流・在庫の変動履歴
需要予測のための販売データの変化
状態が頻繁に変化し、過去の状態が業務の意思決定に影響を与える業務
契約変更や給与計算では、「ある時点の状態」が業務の判断基準となるため、変更履歴が必須です。
特徴
- データの状態が頻繁に変わるため、過去の状態を再現する必要がある。
- 過去の状態に基づいて意思決定を行う必要がある。
業務例
- 契約管理（長期間有効な契約の変更履歴）
保険契約の内容変更（補償範囲の変更、契約者の変更）
通信プランの契約変更（料金プランの変更、オプション追加） - 人事・給与管理
従業員の給与履歴（昇給・降給・手当の追加）
人事評価の履歴（過去の評価データ） - 価格変動の履歴を追う業務
株式・仮想通貨の価格変動履歴
不動産の価格変動履歴
イベントの順序や影響関係が重要な業務
イベントの順序が不明確だと、データの整合性や一貫性が保てなくなるため必要です。
特徴
- あるイベントの発生順序が重要であり、それによって処理の結果が変わる。
- イベントの順序を正しく保持しないと、一貫性が失われる。
業務例
- 注文処理・在庫管理
どのタイミングで注文が確定し、出荷されたのか
返品が発生した場合、いつの注文に紐づくのか - 製造業・プロジェクト管理
生産プロセスの履歴（いつ・どの工程で作業が行われたか）
プロジェクトの変更履歴（仕様変更、納期変更） - トランザクション管理（分散システム）
分散データベースの整合性管理（例えば、分散トランザクションが失敗した場合のロールバック処理）
過去の状態を再現する必要がある業務
過去の状態を特定できないと、不正行為の特定、バグの修正、障害対応が困難になるため必要です。
特徴
- 過去の状態を特定の時点で再現できる必要がある。
- 障害発生時に、過去の状態を復元して問題を調査できる必要がある。
業務例
- 金融取引のリカバリー
特定の時点の株価や取引状態を復元し、不正取引や障害の影響を分析 - ソフトウェア開発・バージョン管理
変更履歴を元に、過去のコードの状態を復元できるようにする（GitやCI/CDのデプロイ履歴） - ゲームのセーブデータ管理
プレイヤーの過去の状態を復元し、ゲーム進行の問題を解決
