Event Stormingとは何か
Event Stormingは、Alberto Brandoliniが考案したワークショップ形式の設計技法である。大きな壁面に付箋を貼り、ドメインイベントを時系列に並べながらドメインの全体像を短時間で可視化する。参加者は開発者だけでなく、ドメインエキスパートや業務担当者を含む。
この技法をDDD実践の文脈で広く知らしめたのはVaughn Vernonである。Vernonは「Domain-Driven Design Distilled」（2016年）の中でEvent Stormingを境界づけられたコンテキスト（Bounded Context）を発見するための実践的な手法として紹介した。
Evans自身は「Domain-Driven Design」（2003年）において境界づけられたコンテキストの重要性を強調したが、その境界をどう発見するかについて具体的な手順は示さなかった。EvansはContextMapという成果物を定義したものの、「どうやって地図を描き始めるか」という問いへの答えは読者に委ねられていた。Event Stormingはその問いに対するVernonの実践的な回答と位置づけられる。
Event Stormingの進め方
Event Stormingは以下の5ステップで進める。各ステップで扱う要素は付箋の色で区別する。
ステップ1: ドメインイベントを洗い出す（オレンジの付箋）
まずビジネス上の意味を持つ出来事（ドメインイベント）をすべて洗い出す。「〜された」という過去形の動詞句で表現する。正確さよりも網羅性を優先し、重複や誤りを恐れずに貼り出す。
ステップ2: コマンドを特定する（青の付箋）
各イベントを引き起こした操作（コマンド）を特定する。「〜する」という命令形で表現し、対応するイベントの左隣に配置する。
ステップ3: アクターを特定する（黄の付箋）
コマンドを実行する人物や外部システム（アクター）を特定し、コマンドに紐づける。採用担当者、候補者、外部の求人媒体システムなど、誰が操作を起こすのかを明示する。
ステップ4: 集約を特定する（黄の大きな付箋）
コマンドを受け取り、イベントを生成する責任を持つ集約（Aggregate）を特定する。コマンドとイベントのペアをグルーピングすることで、どのオブジェクトがどの状態変化を管理するかが明確になる。
ステップ5: 境界づけられたコンテキストを引く
類似した集約、語彙、責務のまとまりを観察し、境界づけられたコンテキストの境界線を引く。この境界は参加者の議論を通じて合意形成されるものであり、最初から正解があるわけではない。
採用管理システムでのEvent Storming実施例
採用管理システムを題材にEvent Stormingを実施すると、以下のドメインイベントが洗い出される。
| ドメインイベント | 英語名 |
|---|---|
| 求人票が公開された | JobPostingPublished |
| 候補者が応募した | CandidateApplied |
| 書類選考が完了した | DocumentScreeningCompleted |
| 面接が設定された | InterviewScheduled |
| 面接が完了した | InterviewCompleted |
| 内定が出た | OfferExtended |
| 内定が承諾された | OfferAccepted |
| 内定が辞退された | OfferDeclined |
これらを時系列に並べると、イベントの性質と語彙のまとまりから境界が自然に浮かび上がる。
求人管理コンテキストは「求人票が公開された」を起点とし、求人票のライフサイクルを管理する。主な集約は JobPosting であり、採用担当者がコマンドを実行するアクターとなる。
候補者管理コンテキストは「候補者が応募した」以降の候補者固有の情報を扱う。候補者のプロフィールや応募履歴を管理する Candidate 集約がここに収まる。
選考管理コンテキストは「書類選考が完了した」から「内定が辞退された」に至る選考プロセス全体を担う。選考の各ステージと結果を管理する Application 集約が中心となる。OfferAccepted と OfferDeclined が同じコンテキストに収まることは、内定の受諾・辞退が選考プロセスの終了条件であることを反映している。
通知コンテキストは、他の3つのコンテキストが発行するイベントを受信し、候補者や採用担当者へのメール通知を担う。通知コンテキストは他のコンテキストに依存するが、他のコンテキストから通知コンテキストへの依存は発生しない。これはEvent Stormingの場でイベントの流れを追ったときに「この通知、誰が送るんだっけ」という議論から自然に分離された経緯を持つ。
この分離プロセスが重要なのは、会議室での議論だけでは気づきにくい語彙の断絶や責務の偏りが、付箋を物理的に動かす作業を通じて可視化されるからである。
Event Stormingの効果
Event Stormingには設計上の複数の効果がある。
ユビキタス言語の確定: イベント名がそのままドメインの語彙となる。JobPostingPublished や OfferDeclined という命名は、ワークショップ参加者の合意のもとで決まるため、コードに落とし込む際にも同じ言葉を使える。Evansが「Domain-Driven Design」で強調したユビキタス言語（Ubiquitous Language）の構築が、設計ドキュメントを書く前の段階で始まる。
境界の可視化: 集約と語彙のクラスタリングによって、どこにコンテキストの境界を引くべきかの仮説が得られる。ContextMapを事後的に描くのではなく、ワークショップ中に境界の候補が浮かび上がる。
実装前のコスト削減: 誤った境界設計は、実装が進んでから発見すると修正コストが大きい。Event Stormingは数時間から1日程度で境界の仮説を検証できる。Vernonが Distilled でこの技法を重視したのは、設計の前段階に投資することで後工程の手戻りを減らすという判断によるものである。
チーム間の認識統一: 開発者とドメインエキスパートが同じ場で同じ付箋を動かすことで、「そのイベントは誰が起こすのか」「このコマンドが失敗した場合どうなるか」といった問いが場に共有される。設計書の読み合わせでは引き出しにくい暗黙知が表面化しやすい。
次章への橋渡し
Event Stormingによって境界づけられたコンテキストの輪郭が得られた。次のステップは、各コンテキスト内部の構造を詳細化することである。
ステップ4で特定した集約——JobPosting、Candidate、Application——はそれぞれ複数の属性と振る舞いを持つ。この集約の内部構造を定義するとき、中心的な概念となるのがエンティティ（Entity）と値オブジェクト（Value Object）である。
次章では、EvansとVernonそれぞれがエンティティと値オブジェクトをどう定義し、どう使い分けを判断しているかを採用管理システムの実装を通じて比較する。
インフォグラフィック
図: 採用管理システムのEvent Storming結果（時系列）
flowchart LR
subgraph JM["求人管理コンテキスト"]
E1["JobPostingPublished\n求人票が公開された"]
end
subgraph KM["候補者管理コンテキスト"]
E2["CandidateApplied\n候補者が応募した"]
end
subgraph SM["選考管理コンテキスト"]
E3["DocumentScreeningCompleted\n書類選考が完了した"]
E4["InterviewScheduled\n面接が設定された"]
E5["InterviewCompleted\n面接が完了した"]
E6["OfferExtended\n内定が出た"]
E7["OfferAccepted\n内定が承諾された"]
E8["OfferDeclined\n内定が辞退された"]
end
subgraph NM["通知コンテキスト"]
N1["通知送信\nNotificationSent"]
end
E1 --> E2
E2 --> E3
E3 --> E4
E4 --> E5
E5 --> E6
E6 --> E7
E6 --> E8
E1 -.->|イベント購読| N1
E2 -.->|イベント購読| N1
E3 -.->|イベント購読| N1
E6 -.->|イベント購読| N1
E7 -.->|イベント購読| N1
E8 -.->|イベント購読| N1