Slicing Event Models

Interview Phase (Optional)

When to Interview: Skip if the user has already specified: available team capacity, sprint duration, MVP scope/timeline, and critical path requirements. Interview when implementation planning details haven't been discussed or when you want to help identify MVP scope.

Interview Strategy: Understand team capacity and timeline constraints to create realistic implementation slices. This shapes MVP scope and parallel work planning.

Critical Questions

When implementation planning is needed:

Available Team Capacity (Impact: Determines how many slices can be built in parallel)
- Question: "How many teams/people are available? (A) 1 team (solo), (B) 2-3 teams, (C) 4+ teams"
- Why it matters: More capacity enables parallel work; small teams need fewer slices to avoid idle time
- Follow-up triggers: If (A) → plan sequential slices; if (C) → maximize parallel work
Sprint/Timeline Constraints (Impact: Affects slice size and MVP scope)
- Question: "What's your sprint duration and MVP deadline? (e.g., 2-week sprints with 8-week deadline, 1-week sprints with 4-week deadline)"
- Why it matters: Tight timelines mean smaller slices; longer timelines allow more ambitious MVP
- Follow-up triggers: If very tight → ask what MUST be in MVP; if loose → ask what nice-to-haves exist
Critical Path & Dependencies (Impact: Determines implementation order and blocking relationships)
- Question: "Are there features that must be built first? (A) No dependencies (parallel from start), (B) Some core features first, (C) Complex dependency chain"
- Why it matters: Understanding dependencies reveals optimal build order and which slices can start immediately
- Follow-up triggers: If (C) → ask what depends on what; map dependency chain

Interview Flow

Conditional Entry:

If user has provided:
  - Team capacity (number of teams/people)
  - AND sprint duration + MVP deadline
  - AND identified critical path / MVP features

Then: Skip interview, proceed directly to slicing

Else: Conduct interview

Phase 1: Capacity Planning (Questions 1-2)

Understand team count
Establish timeline constraints
Determine slice count target

Phase 2: Dependency Mapping (Question 3)

Identify critical path
Determine implementation order
Find parallel work opportunities

Capturing Interview Findings

Document findings to guide slicing:

## Interview Findings: [Domain Name] Implementation Plan

**Team Capacity**: [Number of teams/people]
**Sprint Duration**: [Days/weeks]
**MVP Deadline**: [Date]
**Available Sprints for MVP**: [Number]

**Critical Path Features** (must build first):
- [Feature 1]
- [Feature 2]

**Dependency Chain**:
- [Feature A] blocks [Feature B]
- [Feature B] blocks [Feature C]

**Parallel Work Opportunity**:
- Slice 1 & Slice 2 can start simultaneously
- Slice 3 can start after [dependency]

**Recommended Slices**:
- Slice 1 (Foundation): [features] - [Duration]
- Slice 2 (Features): [features] - [Duration]
- Slice 3 (Extended): [features] - [Duration]

Optional: Write to .trogonai/interviews/[timestamp]-slicing-event-models.interview.internal.trogonai.md.

Event Modeling Slice Skill

Purpose: Break down a complete event model into independently implementable feature slices, identify dependencies, and plan parallel (fan-out) implementation across teams.

Applies To: Any domain - e-commerce, banking, SaaS, marketplace, healthcare, etc.

When to Use:

After completing full event model (Steps 1-9)
Before starting implementation
When planning team allocation and sprint planning
To identify MVP scope
To find what can be built in parallel
To establish implementation order/phases

What It Does:

Identifies feature slices from complete event model
Maps commands, events, and read models to each slice
Identifies slice dependencies
Determines which slices can be developed in parallel (fan-out)
Suggests optimal implementation order
Creates implementation roadmap
Shows data flow between slices

Core Concept: Feature Slices

A Feature Slice is a thin, vertical slice through the entire system:

Feature Slice = Command Handler + [CommandHandler]State + Events + Read Models + Projections
                (complete end-to-end flow for one decision/capability)

Key Characteristics:

Can be implemented independently by one team
Each handler owns its own [CommandHandler]State class
Can be deployed separately
Clear business value (represents one decision/command)
Communicates with other slices via events only
Small enough for one team to implement in 1-2 sprints
Zero merge conflicts (isolated folder with isolated state class)

Feature Slice Identification Framework

Step 1: Group by Business Capability

Start by identifying what users can do:

User Capabilities:
 "Place and confirm an order" ← One slice
 "Pay for an order" ← One slice
 "Manage inventory" ← One slice
 "Fulfill and ship an order" ← One slice
 "Track shipment status" ← One slice

Each capability = One feature slice

Step 2: Map Commands to Slices

Identify which commands belong to each slice:

Feature Slice: Core Order Flow
Commands:
     CreateOrder (customer submits)
     ConfirmOrder (customer confirms)
     (CancelOrder belongs to its own slice)

Feature Slice: Payment Processing
Commands:
     AuthorizePayment (payment gateway)
     ProcessRefund (customer or support requests)

Feature Slice: Fulfillment & Shipping
Commands:
     CreateShipment (fulfillment team)
     ConfirmDelivery (carrier webhook)

Step 3: Map Events to Slices

Identify which events are produced by each slice:

Feature Slice: Core Order Flow
Events Produced:
     OrderCreated
     OrderConfirmed
     OrderCancelled (if cancelled before payment)

Feature Slice: Payment Processing
Events Produced:
     PaymentAuthorized
     PaymentFailed
     RefundInitiated
     RefundCompleted

Feature Slice: Inventory Management
Events Consumed:
     PaymentAuthorized (triggers reservation)
Events Produced:
     InventoryReserved
     InventoryReleased

Feature Slice: Fulfillment & Shipping
Events Consumed:
     InventoryReserved (triggers shipment)
Events Produced:
     ShipmentCreated
     DeliveryConfirmed

Step 4: Map Read Models to Slices

Identify which read models serve each slice:

Feature Slice: Core Order Flow
Read Models:
     OrderDetailView (show what was ordered)
     OrderListView (customer's order history)

Feature Slice: Payment Processing
Read Models:
     PaymentStatusView (payment and refund state)
     OrderPaymentView (payment details per order)

Feature Slice: Inventory Management
Read Models:
     InventoryLevelView (current stock per product)
     ReservationView (what's reserved for which order)

Feature Slice: Fulfillment & Shipping
Read Models:
     ShipmentStatusView (tracking and delivery state)
     OrderFulfillmentView (fulfillment progress per order)

Slice Dependency Analysis

Identifying Dependencies

Dependency Types:

Type 1: Event Dependency
  "Slice B needs events from Slice A"
Example: ReserveInventoryHandler needs PaymentAuthorized (from AuthorizePaymentHandler)
Impact: Must implement Slice A first (publish events)

Type 2: Event Stream Dependency (NOT Aggregate Dependency)
  "Slice B's handler reconstructs state from same event stream as Slice A"
Example: ShipOrderHandler uses OrderCreated/OrderConfirmed events to build ShipOrderState
Impact: Can develop in parallel, but must serialize commands at event store level

Type 3: Read Model Dependency
  "Slice B reads projection from Slice A"
Example: Fulfillment slice needs InventoryLevelView (projected from inventory events)
Impact: Can develop in parallel, but A's projections must deploy first

Type 4: No Dependency
  "Slices are completely independent"
Example: AuthorizePaymentHandler and CreateShipmentHandler work separate event streams
Impact: Can develop, test, and deploy in true parallel

Dependency Matrix Example

              | Core Orders | Payment | Inventory | Fulfillment |

Core Orders  |  (self)    | - | - | - |
Payment      | ← Depends   |  (self)  | - | - |
Inventory    | ← Depends   | ← Depends |  (self)  | - |
Fulfillment  | ← Depends   | ← Depends | ← Depends |  (self)  |

Legend:
  ← Depends on (arrow points to dependency)
  - = No dependency
   = Self (no external dependency)

Fan-Out Implementation Planning

Parallel Development Strategy

CRITICAL PATH (Must do in sequence):
Slice 1: Core Order Flow (foundation)
    ↓ (depends on OrderConfirmed event)
Slice 2: Payment Processing (depends on Slice 1)
    ↓ (depends on PaymentAuthorized event)
Slice 3: Inventory Management (depends on Slice 2)
    ↓ (depends on InventoryReserved event)
Slice 4: Fulfillment & Shipping (depends on Slice 3)

Visual Timeline:
Week 1-2:   [Slice 1: Core Orders] (Team A)
               Unlocks Payment slice

Week 3-4:   [Slice 2: Payment] (Team A)  [Slice 1 integration tests] (Team B)
               Payment unlocks Inventory

Week 5-6:   [Slice 3: Inventory] (Team A)  [Slice 4: Fulfillment] (Team B)
               Can work in parallel once Payment is done

Week 7-8:   Integration & Cross-Slice Testing

Fan-Out Pattern

Fan-Out = One slice (foundation) → Multiple slices (parallel)

Example: Acme Corp Order Management

Slice 1 → Slice 2 → Slice 3 → Slice 4
(Orders)   (Payment)  (Inventory)  (Fulfillment)

Benefits:
   Teams work in parallel
   Slice 1 done in Week 2, teams start Weeks 3-4
   3 teams productive simultaneously
   Critical path stays short
   Risk distributed (if Slice 2 hits issue, Slice 3 continues)

Reference Documentation

For detailed patterns, implementation strategies, and examples:

patterns.md - Slice templates, implementation strategies, communication patterns, MVP scoping, and best practices
examples.md - Complete slice breakdowns, dependency matrices, fan-out timelines, and checklists

Quality Checklist

Each slice contains exactly one complete UI/Processor → Command → Event → Read Model flow
Slice dependencies flow in one direction — no circular dependencies between slices
Each slice is independently deployable — no slice requires another slice to be running to function
Every [CommandHandler]State in a slice is owned exclusively by that slice's handler
MVP scope identifies the minimum set of slices that delivers customer value end-to-end
Fan-out plan assigns each slice to a team with no overlapping handler ownership

eventmodeling-slicing-event-models