Event Modeling

Event Modeling

Event Modeling is how you design event-driven systems before you build them. It’s like creating a movie storyboard for your business processes - visual, concrete, and collaborative.

Visual Business Logic Design

Event Modeling maps out how information flows through your system over time. Instead of abstract requirements documents, you create visual swim lanes that show exactly what happens when users interact with your business.

It’s scenario-based. You work with concrete examples: “When Sarah places an order for pizza, what happens next?”

[Diagram Placeholder: Event Modeling Overview] Visual representation of swim lanes with commands, events, and views

The Color-Coded Building Blocks

Event Modeling uses a simple color system that maps directly to event sourcing concepts:

Blue for Commands

The intent to change something. What users want to do.

• PlaceOrder - Customer wants to buy something
• CancelSubscription - User wants to stop paying
• UpdateProfile - User wants to change their info

Commands are always imperative: “Do this thing.”

Orange for Events

What actually happened. Past tense, immutable facts.

• OrderPlaced - The order was successfully created
• SubscriptionCancelled - The subscription is now inactive
• ProfileUpdated - The user’s info changed

Events are always past tense: “This thing happened.”

Green for Queries/Read Models

Information users need to see to make decisions.

• Order confirmation page
• Account dashboard
• Shopping cart summary

Views show the current state built from events.

Use Case Mapping

Event Modeling organizes scenarios into swim lanes - horizontal flows that show one complete user journey:

[Diagram Placeholder: Event Modeling Swim Lanes] Multiple swim lanes showing different user scenarios

User Experience Swim Lanes

Each swim lane tells one story:

Happy Path: Successful Order Shopping Cart View → Place Order Command → Order Placed Event → Order Confirmation View

Error Path: Out of Stock
Shopping Cart View → Place Order Command → Order Rejected Event → Error Message View

Alternative Path: Guest Checkout Product View → Add to Cart Command → Item Added Event → Guest Checkout View

Every scenario gets its own lane. This forces you to think about:

• What if the item is out of stock?
• What if payment fails?
• What if the user changes their mind?
• What if they’re not logged in?

From Event Model to Code

Event Modeling creates a direct path to implementation:

Commands → DeltaBase Commands

// From your event model
const placeOrderCommand = {
  type: 'PlaceOrder',
  customerId: 'user-123',
  items: [{ id: 'pizza-1', quantity: 2 }]
};

Events → DeltaBase Events

// What gets stored in your event stream
const orderPlacedEvent = {
  type: 'OrderPlaced',
  orderId: 'order-456',
  customerId: 'user-123',
  items: [{ id: 'pizza-1', quantity: 2 }],
  total: 29.98
};

Views → Projections

// Build read models from events
function buildOrderSummaryView(events: OrderEvent[]) {
  return events.reduce((view, event) => {
    switch (event.type) {
      case 'OrderPlaced':
        return { ...view, status: 'placed', total: event.total };
      case 'OrderShipped':
        return { ...view, status: 'shipped' };
      default:
        return view;
    }
  }, initialView);
}

Building Your First Event Model

Start small and concrete:

1. Pick one user journey - “Customer places their first order”
2. Walk through it step by step - What do they see? What do they click?
3. Map the flow - View → Command → Event → View
4. Add error scenarios - What goes wrong? How do users recover?
5. Test with domain experts - Does this match reality?

Don’t try to model everything. One scenario, one swim lane, one story.

Event Modeling vs Event Storming

Event Storming - Discovery workshop to understand the domain

• Chaotic and creative
• Identifies all the things that happen
• Great for learning the business

Event Modeling - Design workshop to plan the solution

• Structured and systematic
• Shows how software supports the business
• Great for building systems

Event Storming asks “What happens in our business?” Event Modeling asks “How do we build software that supports it?”

Common Mistakes

Modeling the database - You’re designing user experiences, not data structures.

Skipping the views - Users need to see information to make decisions.

Being too abstract - Use real customer names, real products, real scenarios.

Trying to be complete - Start with core scenarios, add edge cases later.

Ignoring errors - Happy paths are easy, error handling is where complexity lives.

What You Get

A complete Event Model gives you:

• Shared understanding - Everyone sees the same picture
• Implementation blueprint - Direct path from design to code
• Test scenarios - Concrete examples for validation
• Communication tool - Visual requirements that don’t lie

Event Modeling bridges the gap between business requirements and technical implementation. It’s not just documentation - it’s your system design.

---

Learn more about Event Modeling at eventmodeling.org