{
  "id": "page:library-event-storming",
  "_kind": "Page",
  "_file": "wiki/library/event-storming.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "title": "Event Storming (Library)",
    "displayName": "Event Storming (Library)",
    "slug": "library/event-storming",
    "articlePath": "wiki/library/event-storming.md",
    "article": "\n# Event Storming\n\n> Workshop-based domain modeling using events, commands, and aggregates\n\n## Overview\n\nEvent Storming is a workshop-based method created by Alberto Brandolini for rapidly exploring complex business domains. It uses sticky notes and a timeline to collaboratively model domain events, commands, aggregates, and bounded contexts, bringing domain experts and developers together to build a shared understanding.\n\n**Key Philosophy**: Start chaotic, organize later. Focus on what happens (events), not how it happens.\n\n## Methodology Origin\n\n- **Creator**: Alberto Brandolini\n- **Year**: 2013\n- **Foundation**: Collaborative domain modeling through visual workshops\n- **Core Principle**: Domain events first, then add structure incrementally\n\n## Process Flow\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                        EVENT STORMING                        │\n└─────────────────────────────────────────────────────────────┘\n\n1. BIG PICTURE STORMING (Chaotic Exploration)\n   │\n   ├─ Dump all domain events (orange sticky notes)\n   ├─ Sort chronologically (timeline left to right)\n   ├─ Identify actors (yellow) and external systems (pink)\n   ├─ Mark hot spots - conflicts, questions (red)\n   └─ Group related events into clusters\n\n2. PROCESS MODELING (Add Structure)\n   │\n   ├─ Add commands that trigger events (blue)\n   ├─ Add policies: \"When event X, then command Y\" (purple)\n   ├─ Add read models for queries (green)\n   └─ Detail key process flows\n\n3. SOFTWARE DESIGN (Define Boundaries)\n   │\n   ├─ Identify aggregates - consistency boundaries (lilac)\n   ├─ Define bounded contexts - logical boundaries\n   ├─ Map command handlers\n   └─ Map event handlers\n\n4. CONTEXT MAPPING (Relationships)\n   │\n   ├─ Map relationships between bounded contexts\n   ├─ Apply DDD strategic patterns\n   │   ├─ Shared Kernel\n   │   ├─ Customer-Supplier\n   │   ├─ Anti-Corruption Layer\n   │   └─ Open Host Service\n   └─ Define integration mechanisms (events, APIs)\n\n5. VISUALIZATION (Documentation)\n   │\n   ├─ Event timeline diagrams\n   ├─ Process flow diagrams\n   ├─ Aggregate diagrams\n   ├─ Context map diagrams\n   └─ Domain model summary\n```\n\n## Color Coding\n\nEvent Storming uses color-coded sticky notes to represent different elements:\n\n| Color | Element | Format | Example |\n|-------|---------|--------|---------|\n| **Orange** | Domain Events | Past tense | \"Order Placed\", \"Payment Processed\" |\n| **Blue** | Commands | Imperative | \"Place Order\", \"Process Payment\" |\n| **Yellow** | Actors/Users | Noun | \"Customer\", \"Admin\", \"System\" |\n| **Pink** | External Systems | Noun | \"Payment Gateway\", \"Email Service\" |\n| **Purple** | Policies | When/Then | \"When Order Placed, then Notify Customer\" |\n| **Green** | Read Models | Noun | \"Order History\", \"Inventory View\" |\n| **Red** | Hot Spots | Issue | \"Unclear ownership\", \"Performance risk\" |\n| **Lilac** | Aggregates | Noun | \"Order\", \"Customer\", \"Product\" |\n\n## Three Levels of Event Storming\n\n### 1. Big Picture Event Storming\n**Goal**: Understand the entire domain\n**Duration**: 4-8 hours\n**Participants**: Domain experts, developers, stakeholders\n**Output**: Complete timeline of domain events\n\n### 2. Process Level Event Storming\n**Goal**: Detail specific processes\n**Duration**: 2-4 hours per process\n**Participants**: Process owners, developers\n**Output**: Detailed process flows with commands and policies\n\n### 3. Software Design Event Storming\n**Goal**: Design aggregates and bounded contexts\n**Duration**: 2-4 hours\n**Participants**: Developers, architects\n**Output**: Software architecture with aggregates and contexts\n\n## Usage\n\n### Basic Usage (Full Session)\n\n```javascript\nimport { run } from '@a5c-ai/babysitter-sdk';\n\nconst result = await run('methodologies/event-storming', {\n  projectName: 'e-commerce-platform',\n  domainDescription: 'Online retail platform with orders, payments, and shipping',\n  sessionType: 'full' // Default: all phases\n});\n```\n\n### Big Picture Only\n\n```javascript\nconst result = await run('methodologies/event-storming', {\n  projectName: 'e-commerce-platform',\n  domainDescription: 'Online retail platform',\n  sessionType: 'big-picture' // Only phase 1\n});\n```\n\n### Process Level Only\n\n```javascript\nconst result = await run('methodologies/event-storming', {\n  projectName: 'order-fulfillment',\n  domainDescription: 'Order processing and fulfillment',\n  sessionType: 'process-level' // Phases 1-2\n});\n```\n\n### Refine Existing Model\n\n```javascript\nconst result = await run('methodologies/event-storming', {\n  projectName: 'e-commerce-platform',\n  domainDescription: 'Refined domain model',\n  existingModel: previousResult, // Refine previous session\n  sessionType: 'full'\n});\n```\n\n### Skip Visualization\n\n```javascript\nconst result = await run('methodologies/event-storming', {\n  projectName: 'e-commerce-platform',\n  domainDescription: 'Online retail platform',\n  skipVisualization: true // Skip diagram generation\n});\n```\n\n## Inputs\n\n| Parameter | Type | Required | Default | Description |\n|-----------|------|----------|---------|-------------|\n| `projectName` | string | Yes | - | Name of the project/domain being modeled |\n| `domainDescription` | string | No | '' | High-level description of the domain |\n| `sessionType` | string | No | 'full' | Session type: 'big-picture', 'process-level', or 'full' |\n| `existingModel` | object | No | null | Existing model to refine |\n| `skipVisualization` | boolean | No | false | Skip diagram generation |\n\n## Outputs\n\n### Full Session Output\n\n```typescript\n{\n  success: boolean;\n  projectName: string;\n  sessionType: 'full' | 'big-picture' | 'process-level';\n\n  bigPicture: {\n    events: Array<{\n      name: string;              // \"Order Placed\"\n      description: string;\n      position: number;          // Timeline position\n      triggers: string[];        // What caused this\n      consequences: string[];    // What happens next\n    }>;\n    actors: Array<{\n      name: string;              // \"Customer\"\n      role: string;\n      interactions: string[];\n    }>;\n    externalSystems: Array<{\n      name: string;              // \"Payment Gateway\"\n      purpose: string;\n      interactions: string[];\n    }>;\n    hotSpots: Array<{\n      location: string;          // Where in timeline\n      issue: string;             // What's unclear\n      type: 'conflict' | 'question' | 'complexity' | 'risk';\n    }>;\n    eventClusters: Array<{\n      name: string;\n      events: string[];\n      description: string;\n    }>;\n  };\n\n  processModels: {\n    processes: Array<{\n      name: string;\n      description: string;\n      trigger: string;\n      steps: Array<{\n        type: 'command' | 'event' | 'policy' | 'read-model';\n        name: string;\n        description: string;\n        actor: string;\n      }>;\n    }>;\n    commands: Array<{\n      name: string;              // \"Place Order\"\n      description: string;\n      actor: string;\n      triggersEvents: string[];\n      requiredData: string[];\n    }>;\n    policies: Array<{\n      name: string;\n      trigger: string;           // Event that triggers\n      action: string;            // Command executed\n      condition: string;\n    }>;\n    readModels: Array<{\n      name: string;\n      purpose: string;\n      sourceEvents: string[];\n      consumers: string[];\n    }>;\n  };\n\n  softwareDesign: {\n    aggregates: Array<{\n      name: string;              // \"Order\"\n      description: string;\n      events: string[];          // Events this aggregate produces\n      commands: string[];        // Commands it handles\n      invariants: string[];      // Business rules\n      lifecycle: {\n        creation: string;        // \"Order Created\"\n        updates: string[];       // \"Order Updated\"\n        termination: string;     // \"Order Completed\"\n      };\n    }>;\n    boundedContexts: Array<{\n      name: string;              // \"Order Management\"\n      description: string;\n      aggregates: string[];\n      ubiquitousLanguage: Array<{\n        term: string;\n        definition: string;\n      }>;\n      responsibilities: string[];\n    }>;\n    commandHandlers: Array<{\n      command: string;\n      aggregate: string;\n      validations: string[];\n      producedEvents: string[];\n    }>;\n    eventHandlers: Array<{\n      event: string;\n      handler: string;\n      action: string;\n      targetAggregate: string;\n    }>;\n  };\n\n  contextMap: {\n    relationships: Array<{\n      upstreamContext: string;\n      downstreamContext: string;\n      pattern: 'shared-kernel' | 'customer-supplier' | 'conformist' |\n               'anti-corruption-layer' | 'open-host-service' |\n               'published-language' | 'partnership' | 'separate-ways';\n      description: string;\n      integrationMechanism: 'events' | 'api' | 'shared-db' | 'message-queue' | 'none';\n      dataFlow: string;\n      considerations: string[];\n    }>;\n    integrationPoints: Array<{\n      name: string;\n      contexts: string[];\n      mechanism: string;\n      events: string[];\n      apis: string[];\n    }>;\n    recommendations: Array<{\n      context: string;\n      recommendation: string;\n      rationale: string;\n    }>;\n  };\n\n  visualizations: {\n    eventTimelineDiagram: string;        // Mermaid code\n    processFlowDiagrams: Array<{\n      processName: string;\n      diagram: string;                   // Mermaid code\n    }>;\n    aggregateDiagrams: Array<{\n      aggregateName: string;\n      diagram: string;                   // Mermaid code\n    }>;\n    contextMapDiagram: string;           // Mermaid code\n    domainModelSummary: string;          // Markdown summary\n    implementationRecommendations: Array<{\n      area: string;\n      recommendation: string;\n      priority: 'high' | 'medium' | 'low';\n    }>;\n  };\n\n  artifacts: {\n    bigPicture: string;                  // Markdown file path\n    timeline: string;                    // JSON file path\n    processModels: string;\n    processes: string;\n    softwareDesign: string;\n    aggregates: string;\n    boundedContexts: string;\n    contextMap: string;\n    contextRelationships: string;\n    visualizations: string;\n  };\n}\n```\n\n## Key Principles\n\n### 1. Events First\n- Start with domain events (what happens)\n- Events are facts (past tense, immutable)\n- Events drive the model, not data structures\n- Focus on behavior, not state\n\n### 2. Collaborative Discovery\n- Bring domain experts and developers together\n- Shared language emerges from the session\n- Visual format levels the playing field\n- Questions and conflicts are valuable (mark as hot spots)\n\n### 3. Timeline Organization\n- Left to right temporal flow\n- Chronological order matters\n- Parallel events can occur\n- Focus on \"what\" before \"how\"\n\n### 4. Incremental Structure\n- Phase 1: Chaotic exploration (no order needed)\n- Phase 2: Add structure (commands, policies)\n- Phase 3: Design boundaries (aggregates, contexts)\n- Each phase builds on the previous\n\n### 5. Hot Spot Driven\n- Mark unclear areas with red sticky notes\n- Hot spots indicate:\n  - Conflicts in understanding\n  - Missing information\n  - Complex business rules\n  - Risk areas\n- Address hot spots before implementation\n\n### 6. Aggregates as Consistency Boundaries\n- Aggregate = cluster of related events\n- Consistency boundary (all or nothing)\n- Single responsibility\n- Owns its data and business rules\n\n### 7. Bounded Contexts\n- Logical boundaries around models\n- Each context has own ubiquitous language\n- Contexts can evolve independently\n- Integration through well-defined contracts\n\n## Integration Points\n\n### Compose with Domain-Driven Design\n\nEvent Storming is a tactical tool within DDD:\n\n```javascript\n// 1. Event Storm to discover domain\nconst eventStormResult = await run('methodologies/event-storming', {\n  projectName: 'e-commerce',\n  sessionType: 'full'\n});\n\n// 2. Use bounded contexts to organize implementation\nconst contexts = eventStormResult.softwareDesign.boundedContexts;\n// Implement each context as a separate service/module\n\n// 3. Use aggregates to design entities\nconst aggregates = eventStormResult.softwareDesign.aggregates;\n// Each aggregate becomes a class/module with events and commands\n```\n\n### Compose with Spec-Driven Development\n\nUse Event Storming to inform specifications:\n\n```javascript\n// 1. Event Storm to understand domain\nconst eventStormResult = await run('methodologies/event-storming', {\n  projectName: 'order-processing',\n  sessionType: 'full'\n});\n\n// 2. Convert to specifications\nconst specs = await run('methodologies/spec-driven-development', {\n  projectName: 'order-processing',\n  initialRequirements: `\n    Bounded Contexts: ${eventStormResult.softwareDesign.boundedContexts.map(c => c.name).join(', ')}\n    Aggregates: ${eventStormResult.softwareDesign.aggregates.map(a => a.name).join(', ')}\n    Key Events: ${eventStormResult.bigPicture.events.slice(0, 10).map(e => e.name).join(', ')}\n  `\n});\n```\n\n### Compose with BDD\n\nEvent Storming events become BDD scenarios:\n\n```javascript\n// Event Storm discovers: \"Order Placed\" → \"Payment Processed\" → \"Order Shipped\"\n\n// BDD Scenario:\n// Given a customer with valid payment method\n// When they place an order\n// Then the order should be created\n// And payment should be processed\n// And shipping should be initiated\n```\n\n## Workshop Facilitation Tips\n\n### Before the Session\n- ✅ Invite right participants (domain experts + developers)\n- ✅ Prepare large wall space or virtual board\n- ✅ Stock sticky notes (if physical)\n- ✅ Set expectations: \"start messy, organize later\"\n- ✅ Time box: 4-8 hours for big picture\n\n### During the Session\n- ✅ Start with chaotic exploration (no judgment)\n- ✅ Use past tense for events\n- ✅ Encourage everyone to add sticky notes\n- ✅ Mark hot spots immediately (don't ignore)\n- ✅ Focus on \"what\" not \"how\"\n- ✅ Iterate: add, remove, reorganize\n- ✅ Take photos of the board frequently\n\n### After the Session\n- ✅ Digitize the model\n- ✅ Address hot spots in follow-up sessions\n- ✅ Share artifacts with team\n- ✅ Use model to drive implementation\n- ✅ Update model as understanding evolves\n\n## Common Pitfalls\n\n1. **Jumping to Solutions Too Early**\n   - ❌ Starting with \"how\" before \"what\"\n   - ✅ Focus on events first, design later\n\n2. **Not Involving Domain Experts**\n   - ❌ Developers only session\n   - ✅ Domain experts are essential\n\n3. **Perfect Organization From Start**\n   - ❌ Trying to organize while exploring\n   - ✅ Start chaotic, organize later\n\n4. **Ignoring Hot Spots**\n   - ❌ Skipping over unclear areas\n   - ✅ Mark and address hot spots\n\n5. **Too Much Detail Too Soon**\n   - ❌ Modeling data structures in big picture phase\n   - ✅ High-level events first, details in process phase\n\n6. **Analysis Paralysis**\n   - ❌ Debating every detail\n   - ✅ Move fast, iterate, mark hot spots\n\n## Real-World Examples\n\n### Example 1: E-Commerce Platform\n**Domain**: Online retail with orders, payments, shipping\n**Key Events**: Product Viewed → Cart Updated → Order Placed → Payment Processed → Order Shipped → Delivery Confirmed\n**Aggregates**: Order, Cart, Payment, Shipment\n**Bounded Contexts**: Sales, Payment, Fulfillment, Inventory\n\n### Example 2: Banking System\n**Domain**: Account management and transactions\n**Key Events**: Account Opened → Deposit Made → Withdrawal Requested → Transaction Approved → Balance Updated\n**Aggregates**: Account, Transaction, Customer\n**Bounded Contexts**: Account Management, Transaction Processing, Fraud Detection\n\n### Example 3: Healthcare Platform\n**Domain**: Patient appointments and records\n**Key Events**: Appointment Scheduled → Patient Checked In → Diagnosis Recorded → Prescription Issued → Payment Processed\n**Aggregates**: Appointment, Patient, Prescription\n**Bounded Contexts**: Scheduling, Medical Records, Billing\n\n## References\n\n### Books\n- [Introducing EventStorming](https://leanpub.com/introducing_eventstorming) by Alberto Brandolini\n- [Domain-Driven Design](https://domainlanguage.com/ddd/) by Eric Evans\n- [Implementing Domain-Driven Design](https://vaughnvernon.com/) by Vaughn Vernon\n\n### Online Resources\n- [EventStorming.com](https://www.eventstorming.com/) - Official website\n- [Awesome EventStorming](https://github.com/mariuszgil/awesome-eventstorming) - Community resources\n- [Alberto Brandolini's Blog](https://ziobrando.blogspot.com/)\n\n### Tools\n- **Physical**: Sticky notes, large wall, markers\n- **Digital**: Miro, Mural, FigJam, Lucidspark\n- **Specialized**: EventStorming tools, DDD tools\n\n## Tasks\n\nThis methodology defines the following tasks (all inline):\n\n1. **big-picture-storming** - Discover all domain events, actors, and external systems\n2. **process-modeling** - Model key processes with commands, policies, and read models\n3. **software-design** - Identify aggregates, bounded contexts, and handlers\n4. **context-mapping** - Map relationships between bounded contexts using DDD patterns\n5. **visualization** - Generate diagrams and documentation\n\nAll tasks use agent-based execution with structured output schemas.\n\n## License\n\nPart of the Babysitter SDK Methodologies collection.\n\n---\n\n**Remember**: The goal is shared understanding. The sticky notes are a means to facilitate conversation, not the end product. The real value is the knowledge transfer between domain experts and developers.\n",
    "documents": [
      "specialization:event-storming"
    ]
  },
  "outgoingEdges": [
    {
      "from": "page:library-event-storming",
      "to": "specialization:event-storming",
      "kind": "documents"
    }
  ],
  "incomingEdges": [
    {
      "from": "page:index",
      "to": "page:library-event-storming",
      "kind": "contains_page"
    }
  ]
}