Validating Event Models

Core Architectural Rule (Non-Negotiable)

CRITICAL: Every command must have its own minimal state projection (NOT a DDD Aggregate) What DDD calls an "aggregate root" is actually a READ MODEL. Command handlers must NEVER use read models for validation.

This is the primary validation gate. If a model violates this rule, it fails validation immediately.

VIOLATION EXAMPLE (WILL FAIL VALIDATION):
OrderAggregate { orderId, customerId, items[], total, status, paymentId, address, shippedAt, cancelledAt, ... }
  ↑ This is a READ MODEL, not command state
Used by: ConfirmOrder, ShipOrder, CancelOrder, ApproveReturn
   REJECTED: This is DDD aggregate pattern (a read model), not event sourcing command state

CORRECT PATTERN (PASSES VALIDATION):
ConfirmOrderState { status, orderId }
ShipOrderState { status, orderId, paymentId }
CancelOrderState { status, orderId, createdAt }