ddd-event-storming

DDD イベントストーミング

イベントストーミングは、Alberto Brandolini が考案した、協働型のドメイン探索ワークショップ手法です。ドメインエキスパートと技術チームが付箋を使って協働することで、複雑なビジネスドメインを短時間でモデリングし、集約、境界づけられたコンテキスト、ドメインイベントを導き出します。

ワークフロー

6 ステップのイベントストーミングワークショップ（約 2.5 時間）：

1. ステップ 1：混沌とした探索（30 分）— 自由にアイデアを出し、すべてのドメインイベントを貼り出します（🟠 オレンジ色の付箋）
2. ステップ 2：タイムラインの整理（20 分）— イベントを時系列に並べ、メインフローと分岐を特定します
3. ステップ 3：重要なイベントのマーク付け（15 分）— ビジネスプロセスの転換点に印を付けます（★ マーク）
4. ステップ 4：コマンドと役割（30 分）— 各イベントにコマンドと役割を追加します
5. ステップ 5：集約の発見（30 分）— 関連するイベントを集約としてまとめ、集約ルートに名前を付けます
6. ステップ 6：境界づけられたコンテキストの分割（20 分）— 結合度に基づいて BC を分割し、コンテキストマッピングを決定します

成果物：イベントタイムライン／集約候補／BC マッピング／ホットスポット

参加者の役割：ドメインエキスパート（2～3 人）／開発者（2～3 人）／プロダクト担当者（1 人）／アーキテクト（1 人）

使用する場面

適した場面	適さない場面
新規プロジェクトの立ち上げ時にドメインモデリングが必要な場合	ドメイン知識が十分に文書化されており、直接 domain-designer を使える場合
既存システムのリファクタリングで、ビジネス内容が不明瞭な場合	単独で開発しており、ステークホルダーが参加しない場合
チーム間で協働し、共通言語が必要な場合	ビジネスドメインのない、純粋な技術ツールの開発
マイクロサービスを分割し、サービス境界を決める必要がある場合	ドメインモデルが明確な、単純な CRUD プロジェクト

スキルの境界

スキル	位置付け	使用するタイミング
ddd-event-storming	ワークショップの進行役＋ドメイン探索	プロジェクト初期、複数の役割が協働する場合
ddd-domain-designer	集約の詳細設計＋コードへのマッピング	ワークショップ後、開発前

対象者

このスキルは、バックエンド開発者（DDD アーキテクチャの実装担当）、ソフトウェアアーキテクト（パターンの評価と選定担当）、テックリード（チームの実装内容のレビュー担当）、DDD 初心者（ドメイン駆動設計の基礎を学ぶ方）を対象としています。

6 ステップの詳細

ステップ 1：混沌とした探索 — 30 分

参加者は自由にアイデアを出し、既知のドメインイベントをすべて 🟠 オレンジ色の付箋に書いて貼り出します（動詞の過去形、例：OrderPlaced）。議論は禁止です。進行役は「まず貼り出してから話す」という原則を厳格に守らなければなりません。

活动: 自由贴出领域事件
格式: 动词过去式 (OrderPlaced, PaymentCompleted)
规则: 不讨论、不质疑、不排序
目标: 覆盖所有业务场景，包括异常流

ステップ 2：タイムラインの整理 — 20 分

🟠 イベントの付箋をすべて時系列に並べ、メインフローと分岐を特定します。メインフローは矢印でつなぎ、例外フローはメインフローから分岐させて条件を記載します。

ステップ 3：重要なイベントのマーク付け — 15 分

ビジネスプロセスの転換点に印を付けます。これらは重要なイベント（★ マーク）であり、ドメインモデルの中核となるアンカーです。特徴：後続のフローを開始する、エンティティの状態を変える、コンテキスト間で通信する。

ステップ 4：コマンドと役割 — 30 分

各イベントに 🔵 青色のコマンド（アクションを引き起こすもの）と 🟡 黄色の役割（実行者）を追加します。自動的に発生するイベントにも、コマンドの起動元（System、Scheduler、ExternalSystem）があります。

👤 Customer  →  🔵 Create Order     →  🟠 OrderPlaced
👤 Admin     →  🔵 Approve Refund   →  🟠 RefundApproved
🤖 System    →  🔵 Deduct Stock     →  🟠 InventoryDeducted

ステップ 5：集約の発見 — 30 分

関連するイベントとコマンドを集約としてまとめ、ビジネス用語を使って集約ルートに名前を付けます。集約はトランザクション整合性の境界です。境界内では強い整合性が保たれ、境界間では結果整合性が保たれます。

┌─ Order Aggregate ────────────────────────┐
│ 🟠 OrderPlaced / 🟠 OrderPaid           │
│ 🟠 OrderCancelled / 🟠 OrderCompleted   │
│ 🔵 PlaceOrder / 🔵 PayOrder             │
│ 👤 Customer                              │
│ 聚合根: Order  |  不变式: 已取消不可支付  │
└──────────────────────────────────────────┘

ステップ 6：境界づけられたコンテキストの分割 — 20 分

集約間の結合度とビジネス言語の変化に基づいて BC の境界を定め、マッピング関係を記載します。コンテキストマッピングの種類：Partnership、Shared Kernel、Customer-Supplier、Conformist、Anti-Corruption Layer、Open Host Service。

付箋の色の規則

色	意味	形式の要件	例
🟠 オレンジ色	Domain Event（ドメインイベント）	動詞の過去形	OrderPaid、UserRegistered
🔵 青色	Command（コマンド）	動詞の原形	PayOrder、RegisterUser
🟡 黄色	Actor/Role（役割／参加者）	名詞	Customer、System、Admin
🟢 緑色	Read Model（リードモデル／ビュー）	名詞	OrderDetailPage、Dashboard
🔴 ピンク色	External System（外部システム）	システム名	Alipay、WeChatPay
🟣 紫色	Constraint/Hot Spot（制約／論点）	ビジネスルールの文	注文あたり最大 ¥50000

ワークショップの成果物

成果物：イベントタイムライン（Mermaid シーケンス図）、集約候補、境界づけられたコンテキストマップ（Mermaid C4 図）、コンテキストマッピング、ホットスポット一覧、ユビキタス言語の用語集。

進行のヒント

• 開催前：5 色以上の付箋と大型ホワイトボード／Miro テンプレートを準備します。ドメインエキスパートの参加を必ず確保します。ワークショップの範囲を明確にし、開始 5 分前に色の規則と進行手順を説明します
• 開催中：ステップ 1 では議論を禁止します（最もよくある失敗の原因です）。ビジネス用語を優先します。ホットスポットには紫色の付箋で印を付け、その場で解決しません。タイムボックスを厳守し、参加者の活気を保つようにします
• 開催後：すぐに写真を撮って保存します。24 時間以内に成果物をドメイン文書にデジタル化します。ホットスポットのフォローアップ会議を設定します。成果物を ddd-domain-designer への入力として使用します

オンラインツールの推奨

Miro（分散チーム向け、おすすめ）| Mural（ビデオ会議との連携）| draw.io（無料で軽量）| 物理ホワイトボード（同じ場所に集まるチームに最適）

ddd-domain-designer との関係

推奨パス：event-storming（ワークショップの成果物）→ domain-designer（集約の詳細設計＋コードへの実装）→ Architecture Skill（アーキテクチャの実装）

event-storming では、協働ワークショップの進行（ドメインエキスパート＋チーム全員）に焦点を当て、付箋ボード、イベント一覧、BC の分割（概念レベル）を成果物として作成します。domain-designer では、開発者による集約設計（開発者＋アーキテクト）に焦点を当て、コード構造、集約クラス、リポジトリーインターフェース（コードレベル）を成果物として作成します。

カスタマイズ

場面	調整の提案
小規模チーム（3～5 人）	ステップ 1＋2 を統合し、20 分＋15 分にします。ステップ 6 は省略し、そのまま議論します
大規模チーム（10 人以上）	ステップ 1 を 45 分に延長し、グループに分かれて並行して付箋を貼ります。ステップ 6 にグループ発表の時間を 10 分追加します
時間が限られている場合（1 時間）	ステップ 1～3（イベントの発散＋整理）のみ実施し、後続のステップは別途予定します
複雑なドメイン（複数の BC）	BC ごとにワークショップを 1 回ずつ実施し、1 回ですべてを網羅しようとしないでください
多言語チーム	付箋に 2 言語（中国語のイベント名＋英語の用語）を使用し、中国語での合意を優先します

クイックスタート

要件を AI に直接伝えてください。以下の開始文をそのまま使用できます：

"帮我组织一个电商订单履约的事件风暴工作坊，需要 6 步流程"
"我要做一个保险投保领域的事件风暴，领域专家有 2 位"
"做一次用户中台的事件风暴，重点关注认证和权限"
"之前做完了物流配送的事件风暴，帮我整理产出物"

どこから始めればよいかわからない場合は、「イベントストーミングを手伝って」と伝えるだけで、AI が自動的に進行を案内します。

セキュリティと安全性

このスキルは純粋なドキュメントです。実行可能なスクリプトは含まれておらず、ユーザーデータの収集や、外部サービスおよびネットワークへのアクセスも行いません。

Gotchas — Common Pitfalls

1. 跳过 Brainstorming 直接讨论: 必须先自由发散再排序。过早讨论事件正确性会扼杀创意。
2. 技术人员主导: 必须由领域专家主导，开发做记录和提问。开发主导的模型不是真实业务。
3. CRUD 式命令: 不要写 "CRUD Order"，命令应该是业务动作：PlaceOrder、CancelOrder。
4. 遗忘 Hot Spot: 所有分歧和不确定的边界必须记录为紫色便签。不记录的 Hot Spot 会后被遗忘。
5. 跳过 Aggregate Discovery: 做完 Step 4 就结束。没有 Step 5 的聚类，事件风暴只是漂亮的便签墙。
6. 领域专家缺失: 这是致命错误。没有领域专家参与事件风暴会产出错误的领域模型。
7. 试图一次覆盖整个企业: 范围太大会导致浅尝辄止。建议从核心子域开始，一个 BC 一次。
8. 产出物不整理 → 便签墙变装饰品: 工作坊结束后 24h 内必须将产出数字化，否则记忆会丢失。用 workshop-output-template.md 模板快速整理。
9. 没有通用语言记录: 风暴中自然产生的术语定义的共识，必须记录下来成为 Ubiquitous Language 表。不记录等于没达成共识。

FAQ

问题	回答
工作坊需要多长时间？	一次 BC 约 2.5 小时完整 6 步。中型项目总周期约 2 周。
没有正式领域专家怎么办？	从业务人员/产品经理/有领域经验的高级开发中选择。
线上和线下哪个更好？	线下（实体白板）互动感最强，线上（Miro）可异步协作。
需要多少参与者？	最小 3 人（领域专家+开发+产品），最优 6-8 人。
产出物如何使用？	作为 ddd-domain-designer 的输入，进入聚合详细设计和代码落地。
一个工作坊能覆盖多大范围？	推荐一个 BC 一次。复杂领域可按子域拆分多个工作坊。
主持人必须是 DDD 专家吗？	不需要精通 DDD，但需要理解 6 步流程和颜色规范，具备引导能力。
产出物怎么和代码对应？	聚合候选 → domain-designer Aggregate，事件 → Domain Event 类，BC → 微服务模块。

References

详情见 references/ 和 examples/：

• Templates: sticky-note-template.md, timeline-example.md, workshop-output-template.md
• Guides: facilitation-checklist.md, workshop-deep-guide.md, context-mapping.md, partme-12-event-storming-modeling.md, ddd-strategic.md, clean-ddd-hexagonal-strategic.md
• Examples: 5 个工作坊案例（电商订单履约、保险投保、用户中台、物流配送、金融支付）