From event-modeling
Creates swimlane Event Models for event-driven systems using Adam Dymitruk's methodology. Generates ASCII or Mermaid diagrams at overview, standard, or detailed depths for design and planning.
npx claudepluginhub melodic-software/claude-code-plugins --plugin event-modelingThis skill is limited to using the following tools:
Use this skill when:
Simulates event storming workshops with multi-persona agents to discover domain events, commands, actors, and bounded contexts. Use full-simulation, quick, or guided modes for domain modeling.
Creates BPMN process diagrams using flowchart patterns, including activities, gateways, events, swimlanes, and decision points for workflow documentation.
Guides advanced Event Storming for process, design, and software levels using color-coded sticky notes, facilitation steps, and Brandolini's methodology. For deep domain modeling.
Share bugs, ideas, or general feedback.
Use this skill when:
Create Event Models using Adam Dymitruk's visual methodology for designing event-driven systems.
Before creating Event Models:
docs-management skill for Event Modeling patternsEvent Modeling Structure:
TIME FLOWS LEFT TO RIGHT ───────────────────────────────────────────►
┌─────────────────────────────────────────────────────────────────────┐
│ BLUE: UI / Commands / External Triggers │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Screen/ │ │ Button │ │ API │ │
│ │ Wireframe│ │ Click │ │ Call │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
├──────┼─────────────┼─────────────┼──────────────────────────────────┤
│ ▼ ▼ ▼ │
│ ORANGE: Domain Events (State Changes) │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ OrderPlaced │ │ OrderPaid │ │ OrderShipped │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
├──────┼─────────────────┼───────────────┼────────────────────────────┤
│ ▼ ▼ ▼ │
│ GREEN: Read Models / Projections │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Order List │ │ Payment │ │ Shipping │ │
│ │ View │ │ Status │ │ Dashboard │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
Commands: User intentions that may cause state changes
CHARACTERISTICS:
- Represent user actions or external triggers
- May succeed or fail (validation)
- Produce one or more events on success
- Include wireframes/mockups for UI commands
EXAMPLES:
┌─────────────────────────────┐
│ PlaceOrder │
├─────────────────────────────┤
│ • Customer ID │
│ • Items: [ProductId, Qty] │
│ • Shipping Address │
│ • Payment Method │
└─────────────────────────────┘
Events: Facts that have happened (past tense, immutable)
CHARACTERISTICS:
- Past tense naming (OrderPlaced, not PlaceOrder)
- Immutable once recorded
- Capture what happened and when
- Single source of truth
NAMING CONVENTION:
✓ OrderPlaced
✓ PaymentReceived
✓ ShipmentDispatched
✗ PlaceOrder (command, not event)
✗ OrderUpdate (too vague)
EXAMPLE:
┌─────────────────────────────┐
│ OrderPlaced │
├─────────────────────────────┤
│ • OrderId: guid │
│ • CustomerId: guid │
│ • Items: [...] │
│ • PlacedAt: timestamp │
│ • TotalAmount: decimal │
└─────────────────────────────┘
Read Models: Projections optimized for queries
CHARACTERISTICS:
- Built from events
- Optimized for specific query patterns
- Can be rebuilt from event stream
- Eventually consistent
TYPES:
- List views (showing multiple items)
- Detail views (single item details)
- Dashboards (aggregations)
- Search indexes
EXAMPLE:
┌─────────────────────────────┐
│ OrderSummaryView │
├─────────────────────────────┤
│ • OrderId │
│ • CustomerName │
│ • Status (derived) │
│ • ItemCount │
│ • TotalAmount │
│ • LastUpdated │
└─────────────────────────────┘
Automations: Processes triggered by events
CHARACTERISTICS:
- React to events automatically
- May produce commands or integrate external systems
- Represent business policies
- Handle async processing
NOTATION:
┌─────────────────────────────┐
│ ⚡ PaymentReceivedPolicy │
├─────────────────────────────┤
│ WHEN: PaymentReceived │
│ THEN: InitiateShipment │
└─────────────────────────────┘
Brainstorm all domain events (orange stickies):
1. Gather stakeholders
2. Ask: "What happens in this process?"
3. Write events in past tense
4. Don't worry about order yet
5. Include all significant state changes
Example Output:
- OrderPlaced
- OrderConfirmed
- PaymentReceived
- PaymentFailed
- InventoryReserved
- ShipmentCreated
- ShipmentDispatched
- OrderDelivered
Organize events chronologically:
1. Find the "happy path" events
2. Arrange left to right
3. Group related events vertically
4. Identify parallel flows
5. Note temporal dependencies
Timeline:
OrderPlaced → OrderConfirmed → PaymentReceived → InventoryReserved → ShipmentCreated → ShipmentDispatched → OrderDelivered
│
└→ PaymentFailed → OrderCancelled
What triggers each event?
For each event, ask:
- What user action caused this?
- What external system triggered it?
- Is there a UI screen involved?
Add commands above events they produce:
[PlaceOrder] → OrderPlaced
[ProcessPayment] → PaymentReceived
[DispatchShipment] → ShipmentDispatched
What information is needed for each command?
For each command, ask:
- What data does the user need to see?
- What validation data is required?
- What views enable this action?
Add read models below events that populate them:
OrderPlaced → [OrderConfirmationView]
ShipmentDispatched → [TrackingDashboard]
What happens automatically?
Look for:
- Events that trigger other events
- Integration with external systems
- Time-based rules
- Business policies
Example:
PaymentReceived → ⚡ ReserveInventoryPolicy → InventoryReserved
# Event Model: [Process Name]
## Overview
[What this process accomplishes]
## Actors
- [User type 1]
- [User type 2]
- [External system]
## Event Model Diagram
```text
TIME ──────────────────────────────────────────────────────────────►
COMMANDS (Blue)
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Cmd 1 │ │ Cmd 2 │ │ Cmd 3 │ │ Cmd 4 │
└────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘
│ │ │ │
▼ ▼ ▼ ▼
EVENTS (Orange)
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Event1 │───►│ Event2 │───►│ Event3 │───►│ Event4 │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
│ │ │ │
▼ ▼ ▼ ▼
READ MODELS (Green)
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ View 1 │ │ View 2 │ │ View 3 │ │ View 4 │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
| Command | Input | Produces Events | Read Model Needed |
|---|---|---|---|
| [Name] | [Data] | [Events] | [View] |
| Event | Data | Triggered By | Updates |
|---|---|---|---|
| [Name] | [Fields] | [Command/Automation] | [Read Models] |
| Read Model | Purpose | Updated By Events |
|---|---|---|
| [Name] | [Query it answers] | [Events list] |
| Automation | Trigger Event | Action | Produces |
|---|---|---|---|
| [Name] | [Event] | [What it does] | [Events/Side effects] |
Each slice can be expressed as:
GIVEN: [Read Model State / Context]
WHEN: [Command is executed]
THEN: [Events are produced]
AND: [Read Models are updated]
Example:
GIVEN: Cart exists with items
WHEN: PlaceOrder command executed
THEN: OrderPlaced event recorded
AND: OrderSummaryView updated
AND: InventoryReservationRequested event triggered
A slice includes everything for one feature:
┌─────────────────────────────┐
│ SLICE 1 │
│ ┌─────────────────────┐ │
│ │ Command: PlaceOrder │ │
│ └─────────────────────┘ │
│ ┌─────────────────────┐ │
│ │ Event: OrderPlaced │ │
│ └─────────────────────┘ │
│ ┌─────────────────────┐ │
│ │ View: OrderSummary │ │
│ └─────────────────────┘ │
└─────────────────────────────┘
Each slice is independently implementable and testable.
Event Model becomes implementation blueprint:
1. Commands → API Endpoints / UI Components
2. Events → Event Store Schema
3. Read Models → Database Tables / Views
4. Automations → Event Handlers / Policies
Each slice maps directly to code.
When creating Event Models:
When invoked directly by the user, this skill creates an Event Model for a business process.
For detailed guidance:
Last Updated: 2025-12-26