コンテンツにスキップ
Process Compass（プロセスコンパス）

イベント駆動(Event-Driven Architecture / イベント駆動開発)

既存プロセスの体系 ／ 種別: 設計手法(設計の進め方・考え方)

システム内で起きた「イベント(出来事をデータ化したもの)」を生産者が発行し、ブローカーを介して消費者が非同期に受信・反応することで、生産者と消費者を疎結合に保つ設計パラダイム

ひとことで言うと: 「◯◯が起きた」という出来事を発行し、それに関心のある側が非同期で反応する作り。送り手と受け手が互いを知らなくてよいので疎結合になる。「いつ作るか」ではなく「どう連携させるか」を扱い、スクラム等の内側で使う

全体マップ(第1階層)

各フェーズをクリックすると、フェーズ内のワークフロー(第2階層)へ移動します。

graph LR
  ph0["イベント発見・モデリング"]
  ph1["アーキテクチャ設計"]
  ph0 -->|"イベントの業務妥当性検査"| ph1
  ph2["実装・運用"]
  ph1 -->|"パターン適合検査 / 疎結合・境界検査"| ph2
  gEnd{"結果整合性/一貫性検査"}
  ph2 --> gEnd
  click ph0 "/process-compass/processes/event-driven/modeling/" "イベント発見・モデリングの詳細へ"
  click ph1 "/process-compass/processes/event-driven/architecture/" "アーキテクチャ設計の詳細へ"
  click ph2 "/process-compass/processes/event-driven/implementation/" "実装・運用の詳細へ"

目的と成果

目的(purpose): システムの状態変化をイベントとして表現し、生産者と消費者をブローカー経由で疎結合・非同期に連携させ、リアルタイム応答性・拡張性・(イベントログによる)監査を実現する

成果(outcomes):

  • 生産者は誰が消費するかを知らずにイベントを発行できる(送信側と受信側の脱結合)
  • 新しい消費者をシステム改修なしに追加できる(拡張性)
  • 非同期処理により片方の障害が他方を直接止めない(復元力)
  • 状態変化がイベントログとして残り監査・再構築が可能(イベントソーシング採用時)

原典: 単一の提唱者を持たない。用語 EDA は 2000 年代に Gartner が普及。実務的整理は Martin Fowler(2017)、モデリング手法は Alberto Brandolini の EventStorming(2013頃)

ISO/IEC/IEEE 12207 対応: 主に「テクニカル(アーキテクチャ定義・設計定義、統合・検証にまたがる)」プロセス群をカバー

ロール

ロール責任日本の現場での実態
ドメインエキスパート(Domain Expert)業務で「何が起きるか」の知識源。ドメインイベントの意味・粒度の妥当性を判定する。イベントストーミングの中核参加者業務部門・企画・PdM が兼務。多忙で継続参加できず、開発者が想像でイベントを定義してしまう失敗が起きやすい
アーキテクトパターン選定・トポロジ・ブローカー基盤・スキーマ契約を設計する。疎結合と結果整合性の設計責任テックリードが戦略設計から実装まで一人で抱えがち。EDA 経験者が社内に不足すると設計が属人化する
開発者プロデューサー/コンシューマーの実装、冪等性・順序保証・補償トランザクション(Saga)・可観測性の作り込みサービスごとにチームが分かれ、イベント契約の変更調整が組織横断の負担になる
ファシリテーター(イベントストーミング)部門・専門の壁を越えたワークショップを進行し、イベント・境界・集約の発見を促す外部コンサル/経験者が務めることが多い。社内に経験者がいないと成立しにくい(DDD と共通)

ゲート(決裁・レビュー)

ゲート種別Deliverables判定基準判定者判定結果
イベントの業務妥当性検査検査と適応ドメインイベント一覧各イベントが業務上意味のある確定事実を表すか / 粒度が適切か(技術イベントとドメインイベントの分離)ドメインエキスパート+開発者妥当 / イベント再定義
パターン適合検査検査と適応パターン選定表4パターンが混同されず文脈に合っているかアーキテクト妥当 / パターン差し替え
疎結合・境界検査検査と適応トポロジ図 / コンテキストマップイベント連携が過度な同期依存(分散モノリス)を生んでいないかアーキテクト妥当 / 境界・連携の引き直し
結果整合性/一貫性検査 ※イベント契約(スキーマ)は消費者が広がると事実上の凍結ポイントに近づき、後方互換ルールという軽いガバナンスが自然発生する検査と適応Saga 定義 / スキーマ補償トランザクションで異常系を戻せるか / スキーマ互換性が保たれるかアーキテクト+開発者妥当 / Saga・スキーマ再設計

成果物(information items)

成果物作成者説明
ドメインイベント一覧(イベントストーミングの付箋の壁)ファシリテーター(イベントストーミング)境界・集約・パターン選定の入力。DDD の境界づけられたコンテキスト発見材料
イベントカタログ/スキーマ定義(契約)アーキテクトプロデューサー/コンシューマー間の契約。バージョニング・互換性管理の基盤
トポロジ図(パブ/サブ配線・ブローカー配置)アーキテクト実装のブループリント。メディエータ/ブローカー方式の合意
Saga 定義(手順+補償トランザクション)アーキテクト分散トランザクション実装。結果整合性の作り込み単位

アンチパターン(建前 vs 実態)

分散モノリス

建前(あるべき姿)サービスをイベントで疎結合にし、独立してデプロイ・障害分離できるようにする
実態サービスを分割したが、イベントの裏で同期呼び出し(RPC/HTTP)依存が残り、独立してデプロイ・障害分離できない
なぜ起きるかモデリング(イベントストーミング)を省いて技術先行(Kafka を入れる)で始め、境界設計が甘くなるため
弊害分散システムのコストを払いながらマイクロサービスの利点を享受できない

結果整合性の理解不足

建前(あるべき姿)遅延・重複・順序の乱れを想定し、補償トランザクションと異常系を明示設計する
実態「即時に整合する」前提で UI/業務を作り、遅延・重複・順序を想定しない
なぜ起きるか同期的なトランザクションの感覚のまま非同期システムを作るため
弊害データ不整合・二重処理が本番で表面化する

過剰な複雑性・デバッグ困難

建前(あるべき姿)可観測性(分散トレーシング)を最初から作り込む
実態複数の通知にまたがる論理フローが暗黙的になり、可観測性を後回しにする
なぜ起きるかイベント通知は結合が弱い反面、全体の論理フローがコードのどこにも書かれないため
弊害障害時に何が起きたか追えず、運用で破綻する

建前と実運用(日本の現場)

  • EDA 経験者(アーキテクト)が希少で、モデリングを省いて技術先行で始め境界設計が甘くなる。段階的移行として「モジュラーモノリス」で境界を先に固める国内アプローチが増えている
  • 受託開発ではイベント契約(スキーマ)がサービス=ベンダー境界と一致しがちで、契約変更がそのまま見積・検収の再交渉になり、俊敏なイベント設計の見直しが商流の壁で止まりやすい
  • イベント契約は「決裁ゲートを持つプロセス」と「inspection 型プロセス」の中間例。消費者が広がるほど後方互換ルールという軽いガバナンスが自然発生する

フェーズ一覧(第2階層へ)

参考文献