ddd-event-storming

1 行での概要

Alberto Brandolini が考案した、共同作業によるワークショップ形式です。ドメインの専門家とエンジニアが、物理または仮想の壁に過去形のイベントを左から右への順序で並べてビジネスプロセスをマッピングし、その過程でコマンド、アクター、ポリシー、リードモデル、ホットスポットを明らかにします。

このスキルを使う場面

• グリーンフィールドプロジェクト — コードを書く前に、ドメインと境界づけられたコンテキストを発見します。
• 全容を把握している人がいない既存システム — 暗黙知になってしまったドメイン知識を再構築します。
• チーム間の認識合わせ — ドメインの専門家とエンジニアが同じ場で話し合います。
• 境界づけられたコンテキストの境界の特定 — 単一のコンテキストに収まらないイベントは、多くの場合、境界を示しています。
• 1 つの機能やプロセスの設計 — プロセスモデリングの EventStorming では、1 つのワークフローに焦点を絞ります。

このスキルを使わない場面

• 戦術的なコードレベルの質問 — EventStorming はドメイン発見のためのワークショップであり、コード設計ツールではありません。
• ドメインが十分に理解され、安定している場合 — このワークショップが役立つのは、混乱がある場合や新たな視点が必要な場合です。全員の意見がすでに一致している場合ではありません。
• ドメインの専門家が参加しない場合 — エンジニアだけで EventStorming を行っても、ビジネスの実態ではなく、エンジニアが考える内容を再現することになります。

主な内容

EventStorming の 3 つのレベル（Brandolini）：

• 全体像。 部門やコンテキストをまたぐ、ビジネスプロセス全体です。成果物は、エンドツーエンドで「何が起こるか」を時系列で示した、イベントで埋め尽くされた壁です。通常、半日から 1 日かかります。
• プロセスモデリング。 1 つのプロセスに焦点を絞ります。コマンド（イベントを引き起こすもの）、アクター（コマンドを発行する人）、ポリシー（ルール）、リードモデル（判断に必要なデータ）、外部システムを追加します。通常、プロセスごとに数時間かかります。
• ソフトウェア設計。 さらに細かく掘り下げます。イベントを集約に対応づけます。どのイベントがどの集約を更新するかを決めます。成果物は戦術的モデル、つまりエンティティ、値オブジェクト、リポジトリに直接つながります。

用語（慣例として付箋の色を使用）：

• ドメインイベント（オレンジ） — 過去形で、ビジネス上の意味を持ちます。「OrderPlaced」「RefundIssued」。
• コマンド（青） — イベントを引き起こすものです。「PlaceOrder」「IssueRefund」。
• アクター（黄） — コマンドを発行する人です。「Customer」「Operator」。
• ポリシー（紫） — イベントとコマンドを結びつけるルールです。「支払いに失敗した場合は、24 時間以内に再試行する。」
• リードモデル（緑） — 判断に必要なデータです。「在庫数ビュー」。
• 外部システム（ピンク） — モデルの範囲外にあるものです。「決済プロバイダー」「メールサービス」。
• ホットスポット（赤） — 質問、意見の対立、混乱している領域です。最も価値のある分類であり、赤い付箋はどれも学びの機会です。

進行の流れ。

1. 自由な探索。 全員がイベントを付箋に書き、壁に貼ります。構成も順序も設けません。
2. 時系列の整理。 イベントを時系列に沿って左から右へ並べ替えます。重複はまとめられ、抜けが明らかになります。
3. 重要なイベント。 最も重要な状態遷移を特定します。これらは境界づけられたコンテキストの境界を示すことがよくあります。
4. 時系列をたどる。 最初から最後までストーリーを話し合います。矛盾を明らかにし、イベントを洗練させ、ホットスポットを見つけます。
5. コマンド、アクター、ポリシー、リードモデルを追加する。 周辺の構造を組み立てます。

持ち帰る成果物。 壁の写真（または仮想環境からのエクスポート）。ホットスポットの一覧。境界づけられたコンテキストの初期案。候補となる集約と、それらが発行するイベント。今後確認する未解決の質問。

判断のヒューリスティクス

• ドメインエキスパートは必須です。参加できない場合は、セッションを延期してください。
• 正確性ではなく、参加を優先します。現時点で多少間違っているイベントも、タイムラインをたどる過程で修正されます。
• 最も重要な成果はホットスポットです。赤い付箋はどれも学びの機会です。ワークショップ後に詳しく掘り下げてください。
• まず全体像を把握し、より広い文脈をマッピングしてから、個別のプロセスを詳しく見ていきます。全体像を把握せずにいきなりプロセスモデリングを始めると、モデル化するプロセスを誤って選んでしまいます。
• リモートチームでは、仮想ホワイトボード（Miro、Mural、FigJam）が役立ちます。ただし、可能であれば対面でのセッションのほうが、目に見えて生産的です。

アンチパターン

• ドメインエキスパート不在のEventStorming。 エンジニアリングのアイデアを、ドメインの理解であるかのように取り繕うことです。
• 壁の前に一人だけが立ち、ほかの全員が見ている。 コラボレーションがなければ、共通理解は生まれません。
• 命令形のイベント。 「UpdateOrder」はイベントではなくコマンドです。過去形は必須です。ワークショップで使う語彙は厳密です。
• Big Pictureの前に行うSoftware Design EventStorming。 ビジネスフローを理解せずに集約をモデル化することです。時期尚早です。
• セッション後、模造紙を巻き上げたままにする。 成果物はコード、チケット、またはフォローアップセッションにつなげる必要があります。そうしなければ、ワークショップはフォローアップのない「チームビルディング」になってしまいます。

関連項目

• ddd-design — EventStormingは、ddd-designが最もよく活用するディスカバリー手法の一つです。
• ddd-bounded-context — 重要なイベントからコンテキスト境界が浮かび上がります。
• ddd-ubiquitous-language — イベントは、その言語で使われる語彙になります。
• ddd-domain-event — ワークショップで見つかったイベントを、戦術レベルで形式化したものです。

参考資料

• Alberto Brandolini著、Introducing EventStorming（Leanpub、執筆中） — 標準的な参考資料です。
• Vlad Khononov著、Learning Domain-Driven Design、第12章（EventStorming）。
• Brandoliniによる講演とブログ記事（ziobrando.blogspot.com）。