Eventmodeling Slicing Event Models

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:

1. 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

2. 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

3. 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: 1. Identifies feature slices from complete event model 2. Maps commands, events, and read models to each slice 3. Identifies slice dependencies 4. Determines which slices can be developed in parallel (fan-out) 5. Suggests optimal implementation order 6. Creates implementation roadmap 7. 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](references/patterns.md) - Slice templates, implementation strategies, communication patterns, MVP scoping, and best practices
• [examples.md](references/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

Event Modeling Slice Examples

Table of Contents

• Acme Corp Order Management System
• Slice Interaction Diagram
• Dependency Matrix Example
• Fan-Out Timeline Example
• Checklist for Slice Definition

---

Acme Corp Order Management System

Complete Slice Breakdown

 FEATURE SLICE 1: Core Order Flow

 Business Value: Customers can place and confirm orders
 Effort: 2 weeks / 1-2 engineers
 MVP Critical: YES (foundation for all others)

 Handlers & States:
   - CreateOrderHandler + CreateOrderState
   - ConfirmOrderHandler + ConfirmOrderState
 Events Produced: OrderCreated, OrderConfirmed
 Events Consumed: NONE
 Read Models Created: OrderDetailView, OrderListView

 Upstream Dependencies: NONE (this is foundation)
 Can Run Parallel: NONE (blocks everything else)



 FEATURE SLICE 2: Payment Processing

 Business Value: Orders can be paid and refunded
 Effort: 2 weeks / 1-2 engineers
 MVP Critical: YES (no revenue without payment)

 Handlers & States:
   - AuthorizePaymentHandler + AuthorizePaymentState
   - ProcessRefundHandler + ProcessRefundState
 Events Consumed: OrderConfirmed (triggers payment)
 Events Produced: PaymentAuthorized, PaymentFailed,
                  RefundInitiated, RefundCompleted
 Read Models Created: PaymentStatusView

 Upstream Dependencies: Slice 1 (needs OrderConfirmed event)
 Can Run Parallel: NONE until Slice 1 ships



 FEATURE SLICE 3: Inventory Management

 Business Value: Stock is reserved and released per order
 Effort: 2 weeks / 1-2 engineers
 MVP Critical: YES (prevents overselling)

 Handlers & States:
   - ReserveInventoryHandler + ReserveInventoryState
   - ReleaseInventoryHandler + ReleaseInventoryState
 Events Consumed: PaymentAuthorized (triggers reservation)
 Events Produced: InventoryReserved, InventoryReleased
 Read Models Created: InventoryLevelView, ReservationView

 Upstream Dependencies: Slice 2 (needs PaymentAuthorized)
 Can Run Parallel: Slice 4 (independent once Slice 2 ships)



 FEATURE SLICE 4: Fulfillment & Shipping

 Business Value: Orders are shipped and delivery is confirmed
 Effort: 2 weeks / 1-2 engineers
 MVP Critical: YES (orders must arrive)

 Handlers & States:
   - CreateShipmentHandler + CreateShipmentState
   - ConfirmDeliveryHandler + ConfirmDeliveryState
 Events Consumed: InventoryReserved (triggers shipment)
 Events Produced: ShipmentCreated, DeliveryConfirmed
 Read Models Created: ShipmentStatusView, OrderFulfillmentView

 Upstream Dependencies: Slice 3 (needs InventoryReserved)
 Can Run Parallel: Slice 3 (parallel once Slice 2 ships)

Critical Path

CRITICAL PATH (must do in sequence):
Slice 1 (Week 1-2) → Core Orders, foundation
        ↓
Slice 2 (Week 3-4) → Payment, depends on OrderConfirmed
        ↓
Slices 3 & 4 (Week 5-6) → Inventory & Fulfillment, both depend on PaymentAuthorized
        ↓
Integration & Testing (Week 7-8)

Team Fan-Out

TEAM FAN-OUT:
Week 1-2:  Team A works on Slice 1 (Core Orders)
Week 3-4:  Team A works on Slice 2 (Payment)
             Team B writes integration tests for Slice 1
Week 5-6:  Team A works on Slice 3 (Inventory)
             Team B works on Slice 4 (Fulfillment)
             Both work in parallel once Payment ships!

MVP Options

MVP Option 1 (Minimal):
Launch: Slices 1-2 only (Week 4) - orders can be placed and paid
Later: Add Slices 3-4 (fulfillment)

MVP Option 2 (Full):
Launch: All 4 slices (Week 8) - complete order-to-delivery flow

---

Slice Interaction Diagram

Visual Flow

User Actions:
[Customer places order]
       ↓
[Core Order Flow Slice]
        Command: CreateOrder → ConfirmOrder
        Event: OrderCreated → OrderConfirmed
        Read Model: OrderDetailView
       ↓
[Event Bus: OrderConfirmed]
       ↓

    ↓
[Payment Slice]
        Command: AuthorizePayment
        Event: PaymentAuthorized
        Read Model: PaymentStatusView
       ↓
[Event Bus: PaymentAuthorized]
       ↓

    ↓              ↓
[Inventory Slice]  [Fulfillment Slice]
    Event              Event
    InventoryReserved  ShipmentCreated
    ↓                  ↓

       ↓
    [Read Models Update]
       ↓
    [Display to Users]

---

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 Timeline Example

Visual Timeline

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

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

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

Week 7-8:   Integration & Cross-Slice Testing

Fan-Out Pattern

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

Benefits:
   Sequential until Payment unlocks the fan-out
   Teams A and B work in parallel from Week 5
   Critical path is clear and enforced by event dependencies
   Risk isolated: Inventory issues don't block Fulfillment work

---

Checklist for Slice Definition

Before implementing a slice, verify:

Scope:
[ ] Clear business value statement (one sentence)
[ ] All commands identified
[ ] All events identified
[ ] All read models identified
[ ] No scope creep (staying focused)

Dependencies:
[ ] Upstream dependencies listed (what we need)
[ ] Downstream dependents listed (what depends on us)
[ ] Can we develop in parallel with other slices?
[ ] Do we have all dependencies available?

Boundaries:
[ ] Handler is isolated (own [CommandHandler]State class)
[ ] No shared state classes with other slices
[ ] Events are contract between slices (source of truth)
[ ] Read models owned by one slice, consumed by others

Testability:
[ ] Can this be tested independently?
[ ] Do we have test data without dependent slices?
[ ] Can we mock dependencies?

Deployability:
[ ] Can this be deployed independently?
[ ] Or must we deploy with other slices?
[ ] Database migrations needed? How to coordinate?

Team:
[ ] Right-sized for 1-2 engineers?
[ ] Effort estimated (days)?
[ ] Assigned to team?
[ ] Sprint plan clear?

Event Modeling Slice Patterns

Table of Contents

• Slice Definition Template
• Implementation Order Strategies
• Cross-Slice Communication Patterns
• MVP Scoping with Slices
• Tips for Effective Slicing

---

Slice Definition Template

Use this template for each feature slice:

 Feature Slice: [Name]                                          


BUSINESS VALUE:
What user capability does this enable?
Example: "Buyers can submit reviews and get immediate feedback"

COMMANDS:
  - [Command 1]: What it does
  - [Command 2]: What it does

EVENTS PRODUCED:
  - [Event 1]: When it occurs
  - [Event 2]: When it occurs

EVENTS CONSUMED:
  - [Event from other slice]: Why needed

[COMMANDHANDLER]STATES INVOLVED:
  - [CommandHandler]State class: Which handler owns it, how it's reconstructed

READ MODELS/PROJECTIONS CREATED/UPDATED:
  - [Projection 1]: What events it consumes, what data it produces
  - [Projection 2]: What events it consumes, what data it produces

UPSTREAM DEPENDENCIES:
  "Must complete these slices first:"
  - [Slice X]: Why (what event/aggregate needed)

DOWNSTREAM DEPENDENTS:
  "These slices depend on us:"
  - [Slice Y]: Why (what event/aggregate they need)

CAN RUN PARALLEL WITH:
  - [Slice Z]: Why (no dependencies between us)
  - [Slice W]: Why (independent)

ESTIMATED EFFORT:
  - Development: X days
  - Testing: X days
  - Total: X days

TEAM ASSIGNMENT:
Suggested team size: 1-3 people
Skills needed: [Backend/Frontend/Full-stack]

MVP CRITICAL?
Yes/No (Is this needed for minimum viable product?)

DEPLOYMENT NOTES:
  - Can be deployed independently? [Yes/No]
  - Database migrations? [None/Minor/Major]
  - Configuration changes? [None/Yes]

---

Implementation Order Strategies

Strategy 1: Bottom-Up (Foundation First)

Order:
  1. Core domain slices (most dependencies, fewest dependents)
  2. Mid-layer slices (depend on core, some have dependents)
  3. Presentation slices (few dependencies, most flexible)

Advantage: Stable foundation, reduces rework
Disadvantage: Takes longer to show user value
Best for: Complex systems with many dependencies

Example (Acme Corp Order Management):

Phase 1: Core Order Flow Handlers (foundation - 2 weeks)
   CreateOrderHandler + CreateOrderState
   ConfirmOrderHandler + ConfirmOrderState
   Establishes Order event stream, OrderCreated/OrderConfirmed events

Phase 2: Payment Handlers (depends on Phase 1 - 2 weeks)
   AuthorizePaymentHandler + AuthorizePaymentState
   ProcessRefundHandler + ProcessRefundState
   Uses OrderConfirmed event, produces PaymentAuthorized

Phase 3: Inventory Handlers (depends on Phase 2 - 2 weeks)
   ReserveInventoryHandler + ReserveInventoryState
   ReleaseInventoryHandler + ReleaseInventoryState
   Depends on PaymentAuthorized event

Phase 4: Fulfillment Handlers (depends on Phase 3 - 2 weeks, parallel with 3)
   CreateShipmentHandler + CreateShipmentState
   ConfirmDeliveryHandler + ConfirmDeliveryState
   Depends on InventoryReserved event, builds ShipmentStatusView

Strategy 2: Top-Down (User Value First)

Order:
  1. MVP slices (minimum user value, isolate dependencies)
  2. Core slices (support MVP)
  3. Enhanced slices (nice-to-have features)

Advantage: Show value quickly, get feedback early
Disadvantage: May need refactoring when core changes
Best for: Fast-moving products, MVP validation

Example:

MVP Sprint 1-2: Core Order Flow (minimal, customers can place orders)
   What users need: Create and confirm an order

MVP Sprint 3-4: Payment Processing (enables revenue)
   What the business needs: Authorize and capture payment

Later: Inventory Management (operational feature)
   Prevent overselling, can be manual initially

Later: Fulfillment & Shipping (logistics integration)
   Can be added after payment and inventory are stable

Strategy 3: Risk-Based (De-risk First)

Order:
  1. Uncertain slices (highest risk, validate early)
  2. Dependent slices (build on validated foundation)
  3. Straightforward slices (low risk, can be last)

Advantage: Identifies problems early
Disadvantage: May defer high-value features
Best for: Novel architectures, unproven patterns

Example:

Sprint 1-2: Payment Gateway Integration (highest uncertainty)
   Will the payment provider API behave at scale?
   If this fails, the whole order flow is blocked
   Validate this works before building on it

Sprint 3-4: Core Order Flow (depends on payment working)
   Now we know payment authorization is reliable
   Safe to build order submission on top

Sprint 5-6: Inventory & Fulfillment (low risk)
   Foundation solid, now add operational slices

---

Cross-Slice Communication Patterns

Pattern 1: Event-Driven (Recommended)

Slice A produces event
    ↓
Event published to bus
    ↓
Slice B consumes event
    ↓
Slice B updates its read model

Advantages:
   Loose coupling
   Asynchronous
   Slices don't need to know about each other
   Easy to add new slices

Example:

Slice: Review Submission (produces ReviewPublished)
  ↓
Event: ReviewPublished (published to event bus)
  ↓
Slice: Manual Moderation (listens for ReviewPublished)
Slice: Seller Responses (listens for ReviewPublished)
Slice: Seller Ratings (listens for ReviewPublished)

All three can consume the same event independently

Pattern 2: Event Stream with Multiple Handlers (Correct Approach)

One event stream, multiple independent command handlers
  ↓
Each handler owns its own [CommandHandler]State class
  ↓
Each handler reconstructs its own state from shared events
  ↓
Handlers coordinate via events (eventual consistency)

Advantages:
   Loose coupling (handlers don't call each other)
   Easy to parallelize (each handler is isolated)
   No shared state classes (zero merge conflicts)
   Each handler can deploy independently

Disadvantages:
   Eventual consistency (not immediate)

Example:

Event Stream: Review (ReviewSubmitted, ReviewPublished, ReviewRejected, etc.)

Handlers (all independent):
  - SubmitReviewHandler owns SubmitReviewState
  - ApproveReviewHandler owns ApproveReviewState
  - RejectReviewHandler owns RejectReviewState
  - DeleteReviewHandler owns DeleteReviewState

All handlers process events from same stream
Each maintains its own state in memory during command processing
No shared state class, no coupling, no merge conflicts

Pattern 3: Read Model Dependency

Slice A creates/updates read model
  ↓
Slice B queries read model
  ↓
Slice B shows data to user

Advantages:
   Can develop in parallel
   Slice B independent of Slice A implementation

Disadvantages:
   Eventually consistent
   Slice B deployment depends on Slice A being deployed first

Example:

Slice: Seller Ratings (creates SellerProfileView read model)
  ↓
Slice: Seller Dashboard (queries SellerProfileView)
   Dashboard independent of how ratings are calculated
   But SellerProfileView must be deployed/working

---

MVP Scoping with Slices

Identifying MVP Slices

MVP Principle: Minimum Viable Product
  = Smallest set of slices that provides customer value

Questions to ask:

1. What's the core user problem we're solving?
   Example: "Buyers want feedback on products"

2. What's the minimal slice needed?
   Example: "Review Submission + Display" (not moderation yet)

3. What can we defer?
   Example: "Seller Responses, Ratings, Moderation" (Phase 2+)

4. Which slices must we have for others to work?
   Example: "Submission is foundation, everything depends on it"

MVP Slices:
Priority 1 (Must have): Review Submission
Priority 2 (Nice to have): Seller Responses
Priority 3 (Defer): Manual Moderation, Ratings

MVP Timeline

WEEK 1-2: MVP Launch
   Slice 1: Review Submission & Auto-Publish
     - Buyers can submit reviews
     - Auto-moderation (simple checks)
     - Reviews published immediately (if passes check)
     - Basic review display

Result: Users can submit and see reviews
Revenue impact: Reputation system working
Team effort: 1-2 engineers

WEEK 3-4: Phase 2 Additions
   Slice 2: Seller Responses
     - Sellers can respond
     - Responses published immediately

Result: Two-way conversation
Team effort: 1-2 engineers (parallel)

WEEK 5-6: Phase 3 Operations
   Slice 3: Manual Moderation
     - Admin can approve/reject flagged content

Result: Platform governance
Team effort: 1-2 engineers

WEEK 7-8: Phase 4 Analytics
   Slice 4: Seller Ratings & Dashboard
     - Ratings calculated and displayed
     - Seller dashboard

Result: Reputation metrics visible
Team effort: 1-2 engineers

---

Tips for Effective Slicing

1. Slice by Business Capability, Not Technical Layer

 WRONG (by technical layer):
Slice 1: All command handlers
Slice 2: All event handlers
Slice 3: All read models
Problem: Can't ship anything independently, highly coupled

 CORRECT (by business capability):
Slice 1: Review submission (includes command + event + read model)
Slice 2: Moderation (includes command + event + read model)
Slice 3: Responses (includes command + event + read model)
Benefit: Each slice is shippable independently

2. Keep Slices Thin and Cohesive

 GOOD: One feature per slice
  - Submission slice does submission only
  - Moderation slice does moderation only

 WRONG: Multiple features in one slice
  - "Submission + Moderation" slice
Problem: Harder to parallelize, harder to test

3. Keep Handler State Classes Isolated

If multiple handlers work same event stream:
   SubmitReviewHandler owns SubmitReviewState
     ApproveReviewHandler owns ApproveReviewState
     Both reconstruct from ReviewSubmitted events

Problem (DON'T DO THIS):
     Shared ReviewAggregate class used by both handlers
       Result: Tight coupling, merge conflicts, hard to parallelize

Solution (DO THIS):
     Each handler owns its own [CommandHandler]State class
       Result: Loose coupling, no merge conflicts, easy to parallelize

Read Models:
     Slice 3 & 4 both read SellerProfileView
       Problem: Who creates it?
       Solution: One slice (Rating handler) projects it, others consume

4. Make Dependencies Explicit

For each slice:
[ ] List which handler this slice implements
[ ] List exact events it needs from other handlers
[ ] List exact events it produces
[ ] List exact read models it reads
[ ] List exact read models it creates/updates

Result: Clear contracts between slices

5. Plan Handler Communication

How handlers in different slices connect:
   Event Stream (loosely coupled, asynchronous)
     - Handler A emits event
     - Handler B consumes via event projection
     - No direct dependencies

   Event Stream with Multiple Handlers (loosely coupled, asynchronous)
     - Multiple handlers work same event stream
     - Each owns separate [CommandHandler]State class
     - Coordinated via events (eventual consistency)

   Shared Read Models (loosely coupled, eventually consistent)
     - Slice A projects read model
     - Slice B queries read model
     - Works if A's projections deployed first

   Shared State Classes (tightly coupled, avoid)
     - Both slices share one [CommandHandler]State class
     - Results in merge conflicts and tight coupling
     - Don't do this!