Implement DDD Tactical Patterns

This is a Domain-Driven Design tactical-patterns skill for translating domain rules into code structures - designing aggregate boundaries and invariants, modeling immutable value objects for validated concepts, keeping domain behavior inside domain objects rather than controllers, emitting domain events for meaningful state transitions, and keeping repositories scoped to aggregate root boundaries. Its worked example shows an aggregate enforcing its own invariants directly in a method rather than in a controller:

class Order {
  private status: "draft" | "submitted" = "draft";

  submit(itemsCount: number): void {
    if (itemsCount === 0) throw new Error("Order cannot be submitted empty");
    if (this.status !== "draft") throw new Error("Order already submitted");
    this.status = "submitted";
  }
}

Use this skill when translating domain rules into code structures, designing aggregate boundaries and invariants, refactoring an anemic model into behavior-rich domain objects, or defining repository contracts and domain event boundaries. Don't use it while still defining strategic boundaries - that's a different DDD concern - for API documentation or UI layout tasks, or when full DDD complexity isn't justified for the problem at hand. It explicitly doesn't define deployment architecture or choose databases or transport protocols, and should be paired with testing patterns for invariant coverage rather than relied on alone.

Input is domain rules and the invariants they imply; output is aggregate-scoped code - value objects for validated concepts, domain objects that own their own behavior, domain events for state transitions, and repositories scoped to aggregate roots. Detailed checklists are available in a companion references/tactical-checklist.md file.

Developers refactoring an anemic domain model into behavior-rich aggregates, or designing new domain code from identified invariants, who need concrete tactical DDD patterns rather than strategic-level domain boundary decisions.