Event Sourcing 深掘り ── 経緯・必須要素・デファクトツール・実践と落とし穴

エピローグ ── Event Sourcing を採用すべきか

2026/05/07

エピローグ ── Event Sourcing を採用すべきか

ここまで7章にわたって、Event Sourcing を多角的に見てきた。

Ch.1：「変化を記録する」というパラダイム
Ch.2：複式簿記から始まる500年の系譜
Ch.3：CRUD で失われていた6つの課題
Ch.4：5つの必須要素（Event/Stream/Store/Projection/Snapshot）
Ch.5：6つのデファクトツールと選定軸
Ch.6：10のベストプラクティス
Ch.7：8つのアンチパターン

最終章では、これらを 採用判断の地図 として組み直す。「自分のシステムに Event Sourcing を入れるべきか」「入れるとしてどこから始めるべきか」── この問いに、根拠を持って答えられる状態を目指す。

採用判断フローチャート

flowchart TD
    Start[Event Sourcing 採用検討] --> Q1{この境界文脈で<br/>過去状態の再現が<br/>業務上必要か？}
    Q1 -->|No| CRUD[CRUD で十分]
    Q1 -->|Yes| Q2{変更理由・意図の<br/>追跡が業務上重要か？}
    Q2 -->|No| Q2a{監査要件が<br/>あるか？}
    Q2a -->|No| CRUDplus[CRUD ＋ 履歴テーブル]
    Q2a -->|Yes| Q3
    Q2 -->|Yes| Q3{結果整合性を<br/>受容できるか？}
    Q3 -->|No| Hybrid[CRUD ＋ 同期投影]
    Q3 -->|Yes| Q4{チームの学習コストを<br/>払えるか？}
    Q4 -->|No| Postpone[今回は見送り<br/>パイロット案件で<br/>知見蓄積]
    Q4 -->|Yes| Q5{特定境界に<br/>絞れるか？}
    Q5 -->|Yes| Partial[境界文脈単位で<br/>部分導入]
    Q5 -->|No| Full[全面採用]

    style CRUD fill:#e8f5e9
    style CRUDplus fill:#e8f5e9
    style Hybrid fill:#fff3e0
    style Postpone fill:#fff3e0
    style Partial fill:#e3f2fd
    style Full fill:#e3f2fd

このフローを採用管理システムに当てはめると、こうなる。

Q1：過去状態の再現が必要？
  → Yes（個人情報開示請求対応、選考分析）

Q2：変更理由・意図の追跡が重要？
  → Yes（辞退理由・落選理由は業務上の資産）

Q3：結果整合性を受容できる？
  → Yes（採用ダッシュボードは数秒の遅延を許容できる）

Q4：チームの学習コストを払える？
  → Yes（前提）

Q5：特定境界に絞れる？
  → Yes（選考管理コンテキストのみ ES、応募者プロフィールは CRUD）

→ 結論：選考管理コンテキストに部分導入

「全面採用」がベストな選択肢になることは稀だ。「ここから入れる」と境界を絞れることが、現実的な導入の鍵 になる。

DDD・CQRS・DCB との位置関係マップ

Event Sourcing は他のパターンと組み合わさって機能する。前作と本シリーズで扱った概念群の関係を整理する。

graph TB
    subgraph 前作で扱った世界
        DDD[DDD<br/>ドメイン駆動設計]
        DDD --> Aggregate[集約<br/>Aggregate]
        DDD --> DomainEvent[ドメインイベント<br/>Domain Event]
        DDD --> BC[境界づけられたコンテキスト<br/>Bounded Context]
    end

    subgraph 本シリーズの中心
        ES[Event Sourcing]
        Aggregate -.集約の永続化方式.-> ES
        DomainEvent -.イベントの永続化.-> ES
    end

    subgraph 補完するパターン
        CQRS[CQRS<br/>読み書き分離]
        Saga[Saga<br/>複数集約をまたぐ<br/>プロセス調整]
        Outbox[Outbox<br/>外部配信の<br/>整合性保証]
    end

    ES <-.相性が良い.-> CQRS
    ES --> Saga
    ES --> Outbox

    subgraph 集約の「次」
        DCB[DCB<br/>Dynamic Consistency Boundary]
    end

    Aggregate -.限界を超える.-> DCB
    ES -.前提として要する.-> DCB

    style DDD fill:#fff3e0
    style ES fill:#e3f2fd
    style DCB fill:#f3e5f5

このマップ上での Event Sourcing の位置を、3点に絞って整理する。

位置1：DDD の「次の問い」への答え

DDD は「ドメインモデルをどう設計するか」を扱った。Evans が Domain-Driven Design（2003年）で示したのは、エンティティ・値オブジェクト・集約・リポジトリ・ドメインサービスといったモデリングの語彙だった。

その続きの問い ── 「設計したドメインモデルを、どう永続化するか」「ドメインイベントをどう活用するか」 ── に答えたのが、Vernon の 実装するドメイン駆動設計（2013年）であり、その中で示されたのが Event Sourcing だった。

Evans（2003）：　 ドメインモデルの設計
Vernon（2013）：　モデルの実装と永続化（CQRS / Event Sourcing）

Event Sourcing は DDD の延長線上にある「永続化への答え」 だ。DDD なしでも理論上は使えるが、ドメインの語彙とモデリング規律がない場面で Event Sourcing を導入すると、ch07 のアンチパターン（特に AP1「Updated 地獄」）にまっすぐ突っ込む。

位置2：CQRS との相互補完

前作の第9章で扱った通り、CQRS と Event Sourcing は 独立したパターンだが、組み合わせると相性が良い。

CQRSなし／ESあり：
  Event Store にイベントを書き、それを集約復元にも読み取りクエリにも使う
  → 単純な集約取得には機能するが、複雑なクエリには向かない

CQRSあり／ESなし：
  CRUD で書き、別 DB に Read Model を投影する
  → 機能するが「変化の歴史」は失われる

CQRSあり／ESあり（推奨）：
  Event Store が真実、Projection で Read Model を構築
  → 書き込みは整合性に集中、読み取りは表示要件に最適化
  → イベントが両側を繋ぐ自然な配管になる

「CQRS と ES のどちらを先に入れるか」── 通常は CQRS が先 に来る。CQRS は CRUD のままでも導入できる軽量パターンであり、CQRS の運用に慣れた後で ES に移行する経路が現実的だ。

位置3：DCB という次の世代

2023年に Sara Pellegrini が提唱した DCB（Dynamic Consistency Boundary）は、Event Sourcing を前提として、集約の限界を超える 設計だ。

DDD の集約：
  「設計時に決めた静的な一貫性境界」
  → 業務ルールが集約をまたぐと Saga（複数集約のプロセス調整）／結果整合性で対処

DCB：
  「実行時に動的に決まる一貫性境界」
  → イベントに付与したタグ（業務ID等のラベル）で必要なイベント群を切り出し、
    その範囲だけを atomic に扱う
  → Event Sourcing なしには成立しない

詳細は DCB シリーズで扱う。本章では「集約という静的な箱とは異なる、実行時に決まる範囲」とだけ理解しておけばよい。

つまり、Event Sourcing を採用しておくことは、DCB という「集約の次」へ進む素地を作ること でもある。今すぐ DCB に踏み切らなくても、過去のイベントが型を持って残っているなら、後から境界を再設計できる余地がある。

graph LR
    S1["CRUD<br/>現在の状態のみ"]
    S2["CRUD ＋ 履歴テーブル<br/>変化も別建てで保存"]
    S3["Event Sourcing<br/>変化が真実"]
    S4["Event Sourcing ＋ DCB<br/>境界が動的"]

    S1 -->|変化を記録したい| S2
    S2 -->|履歴と現在のズレが辛い| S3
    S3 -->|集約の境界が窮屈| S4

    S1 -. 戻ることも可能 .-> S2
    S2 -. 戻ることも可能 .-> S3
    S3 -. 戻ることも可能 .-> S4

    style S1 fill:#fff3e0
    style S2 fill:#fff8e1
    style S3 fill:#e3f2fd
    style S4 fill:#f3e5f5

各段階は 不可逆ではない。次の段階に行きやすい設計を、今の段階で取っておくことが大事だ。

このシリーズで身についたこと（チェックリスト）

最初の章で示した「到達点」を再掲し、本シリーズで身についたものを確認する。

☑ Event Sourcing が「いつ・誰が・どんな問題に応えるために」生み出したかを
  人に説明できる
  → Ch.2 で扱った：複式簿記・WAL・Fowler 2005・Greg Young 2010・LMAX

☑ 自分のシステムに Event Sourcing を導入すべきかどうかを
  根拠を持って判断できる
  → Ch.3 の6つの課題と、本章のフローチャート

☑ KurrentDB / Axon / Marten / Akka Persistence などのツールから、
  要件に応じて適切なものを選べる
  → Ch.5 の比較表と3つの判断軸

☑ イベント設計とスキーマ進化、Snapshot 戦略の実装方針を立てられる
  → Ch.4・Ch.6（特に BP5・BP6）

☑ よくあるアンチパターンを設計時点で回避できる
  → Ch.7 の8つのパターンと早見表

身につかなかったこと（次の学習領域）

このシリーズでは深掘りしなかったが、次に踏み込むべき領域がいくつかある。

- Saga / Process Manager の実装パターン
  　複数集約をまたぐ業務プロセスを Event Sourcing 上で実装する詳細
  　→ Vaughn Vernon 「Implementing Domain-Driven Design」を参照

- イベント駆動アーキテクチャ全体（EDA）
  　Event Sourcing の外側、サービス間連携・Choreography の世界
  　→ Sam Newman「Building Microservices」第4章

- 大規模 Event Store の運用
  　数億イベント・複数リージョン・パーティショニング戦略
  　→ KurrentDB / Axon Server の運用ドキュメント

- DCB の実装詳細
  　タグベースのクエリ、楽観的並行性制御の拡張
  　→ DCB シリーズへ

最後に：Event Sourcing は「ふつう」になっていく

冒頭で「Event Sourcing が応える課題は、20年前より『ありふれた要件』になっている」と書いた。本シリーズを通じて、その意味は具体的になったはずだ。

- 監査・コンプライアンスは「特殊な要件」ではなく、ほぼ全ドメインの基本要件
- AI / 分析パイプラインは、業務システムから「自然に流れる」ことが期待される
- 業務の変化が早いので、設計を後から再考できる余地が常に欲しい
- イベント駆動インフラ（Kafka・EventBridge）は前提として整っている

これらの環境変化のもとで、Event Sourcing は「先進的な人だけが使う設計」から「監査と履歴の要求があるなら自然に検討される選択肢」に位置づけが変わってきた。

ただし、ベストプラクティスとアンチパターンの章で見たように、腹落ちせずに導入すると確実に裏目に出る。「変化を記録する」というパラダイムは、CRUD とは別のメンタルモデルを要求する。チームが慣れる時間を確保すること、最初の境界を絞ること、後戻りできる設計にしておくこと ── この3つが揃えば、Event Sourcing は強力な武器になる。

参考文献・情報源

古典・原典

Martin Fowler “Event Sourcing” (2005) ── 用語を確立した記事
Martin Fowler “Domain Event” (2005) ── イベントを設計の語彙にした記事
Greg Young “CQRS Documents” (2010, PDF) ── CQRS と ES をセットで体系化
Greg Young “CQRS and Event Sourcing” Blog (2010)
Martin Fowler “The LMAX Architecture” (2011) ── Event Sourcing が大規模で動くことの実証
Vaughn Vernon「実装するドメイン駆動設計」(2013) ── DDD の実践書として ES を扱う

ツール公式

検証ノート

本シリーズの執筆にあたり、以下の事実関係を WebSearch / 公式ドキュメントで確認した。

- Martin Fowler "Event Sourcing" 公開日：2005年12月12日（martinfowler.com）
- EventStoreDB → Kurrent リブランド：2024年11月（公式FAQ）
- KurrentDB バージョン：25.0 が最初のリブランド版
- Axon Framework 累計70Mダウンロード超（公式サイト）
- Marten：JasperFx Software による開発、PostgreSQL ＋ .NET、MIT ライセンス
- Akka 2.7 以降 BSL 1.1 ライセンス（2022年9月発表、36ヶ月後に Apache 2.0 へ自動転換）
- Apache Pekko：Akka 2.6 系の Apache 2.0 フォーク

事実上の確認はしたが、ツールのバージョンや細かい仕様は本シリーズ公開後も変化する。導入時には公式ドキュメントの最新版を確認してほしい。

ここで本シリーズは終わる。Event Sourcing は「変化を記録する」という設計だ。だがそれは結局のところ、「業務の真実をソフトウェアの中で正直に表現する」 ための1つの方法論にすぎない。ツールが何であれ、設計の重心は常に 「ドメインで何が起きているか」を理解すること にある。

採用管理システムの選考プロセスから始まり、複式簿記まで遡り、6つのツールを比較し、10のベストプラクティスと8つのアンチパターンを見てきた。この地図を持って、自分のシステムの「変化」をどう記録するか、考え始めてほしい。

それが Event Sourcing を学ぶ、本当の出発点だ。

エピローグ ── Event Sourcing を採用すべきか

採用判断フローチャート

DDD・CQRS・DCB との位置関係マップ

位置1：DDD の「次の問い」への答え

位置2：CQRS との相互補完

位置3：DCB という次の世代

このシリーズで身についたこと（チェックリスト）

身につかなかったこと（次の学習領域）

最後に：Event Sourcing は「ふつう」になっていく

参考文献・情報源

古典・原典

ツール公式

関連シリーズ（前作・関連作）

検証ノート