イベントストーミング — 業務からモデルを見つけるワークショップ

前章で、境界をどこに引くかが戦略的設計の中心だと書きました。では、その境界をどうやって見つけるのか。

本章で扱うイベントストーミングは、その問いに対する道具のひとつです。Alberto Brandolini が考案した手法で、公式サイトは「複雑なビジネスドメインを協調的に探索するための、柔軟なワークショップ形式」と定義しています¹。

何のための道具か

イベントストーミングは設計手法ではありません。業務を知っている人と、コードを書く人が、同じ壁の前に立つための仕掛けです。

通常、業務の知識は担当者の頭の中にあり、開発者はそれを要件定義書という形で受け取ります。書類を経由すると、「なぜそうなっているか」が落ちます。「金曜の出荷分だけ締め切りが早い」という運用が、書類では「金曜は 15 時締め」としか書かれず、理由 (配送業者の集荷が早い) が伝わりません。理由を知らないまま実装すると、配送業者が変わったときに何を直せばいいか分からなくなります。

壁に付箋を貼りながら話すと、この「なぜ」がその場で出ます。担当者が付箋を動かしながら「あ、ここは例外がある」と言い出す場面が、要件定義書からは出てきません。

3 つの粒度

Brandolini の書籍は、目的の違う 3 つの形を扱っています²。

粒度	何を見るか	参加者
Big Picture	事業全体の流れ。どこに問題があるか	業務・開発・経営を横断
Process Modeling	1 つの業務プロセスの詳細。判断と分岐	その業務の担当者と開発者
Design-Level	実装に落とすためのモデル。集約の候補	主に開発者

最初にやるなら Big Picture です。いきなり Design-Level から始めると、業務の全体像を共有しないまま実装の議論に入ることになり、後から「その業務はそもそも別のシステムが持っている」と分かる事故が起きます。

本ガイドの範囲で効くのは Big Picture と Design-Level です。前者で第 5 章の境界の候補を見つけ、後者で第 10 章の集約の候補を見つけます。

付箋の文法

イベントストーミングの中心は色分けです。主に使う色は次のとおりで、ほかにも機会や価値を表す色があります。ただし色そのものより、イベントを過去形で書くという文法のほうが本質的です。

色	表すもの	書き方
オレンジ	ドメインイベント	過去形の動詞。「注文が確定された」
青	コマンド (意図・行動)	命令形。「注文を確定する」
黄 (小)	アクター	人・部署・チーム
黄 (大)	制約	業務上の決まりごと。「確定後は変更できない」
紫	ポリシー	「〜が起きたら、〜する」
緑	参照モデル	判断に必要な情報
ピンク (幅広)	外部システム	決済サービス、配送業者の API
ピンク (蛍光)	ホットスポット	疑問、対立、言葉の食い違い

出典は ddd-crew/eventstorming-glossary-cheat-sheet です。同資料は Domain Event を "A Domain Event is a verb at the past tense" (過去形の動詞) と定義しています。

付箋はこう並ぶ

色には並べ方の決まりがあります。誰かが何かをして (アクター → コマンド)、その結果が起き (イベント)、それを引き金に次が動く (ポリシー → 次のコマンド) という連鎖です。

実線が主な連鎖、点線が付随する要素です。この連鎖が壁の左から右へ時間順に伸びていきます。

読むときのルールは 4 つです。

ルール	内容
左から右へ時間が流れる	縦の位置に意味はない。同時に起きることは縦に並べる
イベントとイベントのあいだには必ず理由がある	自動で起きるならポリシー、人が起こすならコマンドとアクターが入る
コマンドは失敗しうる、イベントは失敗しない	「注文を確定する」は拒否されうるが、「注文が確定された」は起きた事実
説明できない飛びはホットスポット	「ここで何が起きているか分からない」を隠さず蛍光ピンクで残す

3 つ目が実装に効きます。コマンドが失敗する条件は、そのままエンティティのビジネスルール (第 9 章) になります。「明細が空なら確定できない」という制約は、壁の上では青い付箋の脇に書かれ、コードでは Order::confirm() の中の例外になります。

注記

Big Picture の段階では、集約は出てきません。「誰が何をして何が起きたか」だけを並べます。そもそも集約に対応する付箋の色は無く、黄の大きい付箋が表すのは制約です。集約の候補が見えるのは、同じコマンドで一緒に変わるイベントが揃ってからで、それは Design-Level の作業です (後述)。

なぜ過去形が効くのか

過去形で書くと、起きた事実だけが残ります。「注文を確定する」は機能の説明ですが、「注文が確定された」は業務で起きた出来事です。

機能で書くと、既存システムの画面や操作に引きずられます。「注文確定ボタンを押す」と書いた瞬間、ボタンがある前提の設計になります。事実で書けば、それが自動で起きるのか人が操作するのかは後から決められます。

ホットスポット (蛍光ピンク) は軽く見られがちですが、境界の候補が最も出やすい付箋です。参加者のあいだで「その『商品』は何を指しているのか」が食い違ったとき、そこに 2 つのコンテキストが重なっています。

Big Picture の進め方

Brandolini の書籍は Big Picture ワークショップを段階に分けています。要点は次の流れです。

混沌の探索から時系列へ

最初の段階では、参加者が思いつくイベントをばらばらに貼ります。この時点で順序を整えません。順序を先に決めようとすると、発言する人が一人に絞られ、他の参加者が知っている出来事が出てこなくなります。

全員が貼り終わってから、時系列に並べ替えます。ここで重複が見つかり、「同じことを別の言葉で呼んでいた」が表に出ます。EC の注文なら、こういう並びになります。

注文が確定された → 在庫が引き当てられた → 決済が完了した → 出荷が指示された → 商品が発送された

並べ替えの途中で、順序について意見が割れる場所が出ます。「決済の前に在庫を引き当てるのか、後か」で担当者どうしの認識が違ったら、そこにホットスポットを貼ります。この食い違いは設計の判断に直結します — 在庫を先に押さえるなら決済失敗時の解放が要り、後なら在庫切れで決済の取り消しが要ります。

出てきたものが設計にどう繋がるか

ここが本章の中心です。壁に貼った付箋は、実装のどこかに対応します。

付箋	落ちる先	扱う章
オレンジ (イベント)	ドメインイベント	第 12 章
青 (コマンド)	ユースケースの入力	第 15 章
紫 (ポリシー)	イベントのリスナー、またはドメインサービス	第 11 章 / 第 12 章
黄 (アクター)	認可の主体	第 22 章
ピンク (外部システム)	腐敗防止層	第 5 章
ピンク蛍光 (ホットスポット)	境界の候補	第 5 章

この表の右側は、多くがこれから読む章です。ここでは対応だけを示します。それぞれが何なのかは、各章で実装と一緒に扱います。

注文の例で具体的に見ます。壁にこう並んだとします。

付箋	内容
青 (コマンド)	注文を確定する
黄 (アクター)	購入者
オレンジ (イベント)	注文が確定された
紫 (ポリシー)	注文が確定されたら、在庫を引き当てる
オレンジ (イベント)	在庫が引き当てられた

これは実装ではこうなります。

// 青の付箋 → ユースケースの入力
final class ConfirmOrderCommand
{
    public function __construct(
        public readonly int $orderId,
    ) {}
}

// オレンジの付箋 → ドメインイベント。付箋の言葉がそのままクラス名になる
final class OrderConfirmed
{
    public function __construct(
        public readonly OrderId $orderId,
        public readonly DateTimeImmutable $occurredAt,
    ) {}
}

// 紫の付箋 → イベントのリスナー。「〜が起きたら〜する」がそのまま形になる
final class ReserveInventoryOnOrderConfirmed
{
    public function handle(OrderConfirmed $event): void
    {
        // 在庫の引当。実装は第 11 章と第 12 章で扱う
    }
}

付箋の言葉とクラス名が一致していることが、第 5 章のユビキタス言語です。業務の担当者が「注文が確定された」と呼ぶものが、コードでも OrderConfirmed になっていれば、仕様の議論とコードの議論が同じ語で進みます。

集約の候補を見つける

Design-Level まで進むと、集約の候補が見えます。同じコマンドで一緒に変わるイベントは、同じ集約に属している可能性が高いです。

注文の確定で「注文が確定された」と「注文明細が確定された」が同時に起きるなら、注文と明細は 1 つの集約です。一方、「在庫が引き当てられた」は別のタイミングで起きても業務が成立するので、別の集約になります。

この判断の詳細は第 10 章が扱います。ここで押さえるのは、集約の境界が机上でなくワークショップの観察から出てくるという点です。

付箋と集約のあいだにあるもの

候補が見えることと、集約が決まることは別です。EventStorming の側は、集約という語を意図的に語彙から外しています。以前は集約と呼んでいた黄の大きい付箋は、いまは制約 (Constraint) です³。業務の担当者と同じ壁の前に立つ手法なので、設計側の語を持ち込まない、という判断です。

同じ資料は、Big Picture から立ち上がってくるものを "Emerging Bounded Contexts" と呼び、それを「どこから深掘りを始めるかの最初の指標」と位置づけています。Big Picture の壁から出てくるのは境界の当たりであって、集約の定義ではありません。

集約そのものを設計する段には、別の道具が用意されています。ddd-crew の Aggregate Design Canvas は、集約 1 つを 9 項目で書き出す用紙です。埋めていく過程で境界の置き方が問われるので、候補を検証する道具として使えます。9 項目のうち境界の検算に効く 3 つは、第 10 章が本ガイドの基準として扱います。

ワークショップから実装までの道具立ては ddd-crew/ddd-starter-modelling-process に段階ごとにまとまっていて、段階ごとに「まずこれから」と勧める道具が挙がっています。ただし同資料は冒頭で、これは初心者向けであり、"a linear sequence of steps that you should standardise as a best practice" (標準的な手順として固定すべき一連の流れ) ではないと断っています。推奨されているのは各段階で使う道具であって、その並びではありません。

やってみるときの注意

• 開発者だけでやらない。業務の担当者がいないと、既存のコードの構造を壁に貼り直すだけになります。新しい発見が出ません
• 時間を区切る。Big Picture は半日から 1 日かかります。最初は 2 時間で範囲を狭く切るほうが、全体を一度やるより続きます
• CRUD を貼らない。「注文が登録された」「注文が更新された」は業務の言葉ではありません。何が起きたかを聞き直すと、「注文が確定された」「配送先が変更された」のように分かれます
• 最初から正しく並べようとしない。混沌の探索を飛ばすと、声の大きい人の認識だけが壁に残ります

オンラインでやる場合は、Miro や Mural のような無限に広がるキャンバスを使います。付箋の数が数百枚になるので、画面の広さが制約になります。

業務を物語として描く手法

業務を知るための道具は付箋だけではありません。Domain Storytelling は、業務を 1 本の物語として絵と矢印で描きます。

登場する人や仕組みを actor、やりとりされる書類や物を work object と呼びます。両者を矢印で結んで動詞を書けば 1 文になり、矢印に振った番号が文の順序になります。「出札係が座席表を見る」「出札係が空席を来場者に伝える」と 1 文ずつ並べていく形です。分岐を先に描かないのが要点です。まず典型的な筋を 1 つ通し、他に何が起こりうるかはその後に集めます。

2 つは排他ではありません。公式の Quick-Start Guide は、物語を描いたあと EventStorming などで会話を続けられると書いています。

まとめ

ポイント	内容
目的	業務を知る人と書く人が同じ壁の前に立つ。要件定義書では落ちる「なぜ」を拾う
粒度	Big Picture から始める。Design-Level は実装の直前
文法	イベントは過去形。色より、起きた事実で書くことが本質
ホットスポット	言葉の食い違いが出た場所が、境界の候補
設計への接続	オレンジ→ドメインイベント / 青→ユースケース / 紫→リスナー
別の記法	Domain Storytelling は業務を 1 本の物語として描く。排他ではなく併用できる

ここまでが戦略的設計です。次章から、境界の内側をどう作るかに入ります。

参考資料

• EventStorming 公式サイト — 考案者 Alberto Brandolini による定義とワークショップの形式
• Alberto Brandolini『Introducing EventStorming』(Leanpub) — 原典。Big Picture / Process Modeling / Design-Level をそれぞれ独立した章で扱う
• ddd-crew/eventstorming-glossary-cheat-sheet — 付箋の色と概念の対応表
• ddd-crew/ddd-starter-modelling-process — 業務の理解から実装までを段階に分け、段階ごとに使う道具を挙げた資料
• ddd-crew/aggregate-design-canvas — 集約 1 つを 9 項目で書き出す用紙
• Domain Storytelling — 業務を 1 本の物語として絵に描く手法。記法は Quick-Start Guide にまとまっている
• 成瀬允宣「イベントストーミングによるオブジェクトモデリング」 (Object-Oriented Conference 2024) — 日本語の発表。ワークショップの実演を含む

Footnotes

1. EventStorming 公式サイト ↩

2. Alberto Brandolini『Introducing EventStorming』(Leanpub)。同書は Big Picture のワークショップ、Process Modeling、Design-Level をそれぞれ独立した章で扱っています。 ↩

3. ddd-crew/eventstorming-glossary-cheat-sheet は、集約を EventStorming では公式に過去の語 ("officially a legacy word") としたうえで、業務の関係者に対してその語を使わないためだと説明しています。 ↩