Implement DDD Tactical Patterns

DDD Tactical Patterns applies Domain-Driven Design tactical patterns in code: entities, value objects, aggregates, repositories and domain events, with explicit invariants. Its instructions: identify invariants first and design aggregates around them; model immutable value objects for validated concepts; keep domain behavior inside domain objects rather than controllers; emit domain events for meaningful state transitions; and keep repositories at aggregate-root boundaries.

Its worked example is a TypeScript Order class whose submit() method enforces two invariants directly in the domain object - the order cannot be submitted empty and cannot be submitted twice - by throwing before changing its status field:

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";
  }
}

The reference file, references/tactical-checklist.md, expands this into a checklist across four areas: aggregate design (one aggregate root per transaction boundary, invariants enforced inside aggregate methods, avoid cross-aggregate synchronous consistency rules); value objects (immutable by default, validated at construction, equality by value rather than identity); repositories (persist and load aggregate roots only, expose domain-friendly query methods, avoid leaking ORM entities into the domain layer); and domain events (past-tense event names such as OrderSubmitted, minimal and stable event payloads, and versioning the event schema before making a breaking change).

Use it for 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. Do not use it while still defining strategic boundaries between bounded contexts (a separate concern), for tasks that are only API documentation or UI layout, or when the full complexity of DDD is not justified for the problem at hand.

Input is the domain rules and invariants that need to be modeled. Output is aggregate and value-object code with invariants enforced inside domain methods, repository contracts scoped to aggregate roots, and domain events named in the past tense with versioned payloads. Three limitations: this skill does not define deployment architecture, it does not choose databases or transport protocols, and it should be paired with testing patterns for invariant coverage.

It suits developers implementing or refactoring a domain model who need aggregates, value objects, repositories and domain events designed around explicit business invariants rather than an anemic, logic-free data model.