tactical-ddd
Tactical-ddd detects anemic domain models lacking behavior and refactors code into rich domain models following Domain-Driven Design patterns. Use this skill when validating domain model quality, identifying encapsulation problems, converting anemic entities into proper Entities or Value Objects, or improving compliance with tactical DDD building blocks like Aggregates and Domain Events.
git clone --depth 1 https://github.com/tech-leads-club/agent-skills /tmp/tactical-ddd && cp -r /tmp/tactical-ddd/packages/skills-catalog/skills/(architecture)/tactical-ddd ~/.claude/skills/tactical-dddSKILL.md
# Tactical DDD — Rich Domain Modeling ## Workflow Determine the user's intent first: | Intent | Phases to run | |--------|--------------| | "validate / review / check / is this correct?" | Phase 1 + 2 only → report findings, ask before refactoring | | "fix / refactor / improve / clean up" | Phase 1 + 2 + 3 | | "how should I design / model this?" | Load [reference.md](reference.md) directly | ### Phase 1 — Detect Load [detection.md](detection.md) and scan the target code for anemia signals. Produce a severity score and list of affected classes. ### Phase 2 — Assess For each affected class, determine the correct building block: | Has unique identity tracked over time? | Has invariants tying multiple objects? | → Building Block | |----------------------------------------|----------------------------------------|-----------------| | Yes | — | **Entity** | | No | — | **Value Object** | | Yes (root) + children with shared invariants | Yes | **Aggregate** | | Operation spans multiple Aggregates/doesn't belong to any | — | **Domain Service** | Prefer Value Objects over Entities. Prefer small Aggregates over large ones. **If intent was validate/review**: stop here. Report findings using the output format below. Ask "Would you like me to apply these fixes?" before proceeding. ### Phase 3 — Refactor Load [refactoring.md](refactoring.md) for step-by-step moves. Apply in this order: 1. Replace setter chains with a single expressive method 2. Move service logic into the Aggregate that owns it 3. Add business guards at the top of each method 4. Publish a Domain Event after each successful state change 5. Replace primitive types with Value Objects For deep pattern questions (boundary design, event modeling, service vs. entity decision), load [reference.md](reference.md). --- ## Quick Anemia Signals (scan first) ``` public setX() / public setY() → behaviour should be encapsulated service.doX(entity, ...) → logic likely belongs in entity entity.setA(); entity.setB(); ... → setter chain = missing intent method no domain methods beyond getters → pure data bag ``` --- ## Golden Rules 1. **Behaviour with data** — Objects own both state and the operations that change it 2. **Ubiquitous Language** — Method names come from the domain, not CRUD (`commitTo`, not `setStatus`) 3. **Small Aggregates** — Root + Value Objects by default; add child Entities only for true invariants 4. **One transaction = one Aggregate** — Cross-Aggregate rules use eventual consistency via Domain Events 5. **Reference by ID** — Never hold object references to other Aggregates 6. **Value Objects first** — Use Entities only when individual identity is essential 7. **Domain Services sparingly** — Excessive services → anemic model 8. **Protect invariants** — The Aggregate is the last line of defence; never trust the caller --- ## Output Format When reviewing code, report: ``` ## Anemia Diagnosis: <ClassName> Severity: [None | Mild | Moderate | Severe] Issues: - <description of problem> Recommended refactoring: - <specific move from refactoring.md> ``` When refactoring, show a before/after diff for each class touched.
Finds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before refactoring. Do NOT use for code-level duplication detection (use linters) or dependency analysis (use coupling-analysis).
Detects misplaced classes and fixes component hierarchy problems — finds code that should belong inside a component but sits at the root level. Use when asking "clean up component structure", "find orphaned classes", "fix module hierarchy", "flatten nested components", or analyzing why namespaces have misplaced code. Do NOT use for dependency analysis (use coupling-analysis) or domain grouping (use domain-identification-grouping).
Maps architectural components in a codebase and measures their size to identify what should be extracted first. Use when asking "how big is each module?", "what components do I have?", "which service is too large?", "analyze codebase structure", "size my monolith", or planning where to start decomposing. Do NOT use for runtime performance sizing or infrastructure capacity planning.
Analyzes coupling between modules using the three-dimensional model (strength, distance, volatility) from "Balancing Coupling in Software Design". Use when asking "are these modules too coupled?", "show me dependencies", "analyze integration quality", "which modules should I decouple?", "coupling report", or evaluating architectural health. Do NOT use for domain boundary analysis (use domain-analysis) or component sizing (use component-identification-sizing).
Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices strategy", or tracking decomposition progress. Do NOT use for domain analysis (use domain-analysis) or component sizing (use component-identification-sizing).
Maps business domains and suggests service boundaries in any codebase using DDD Strategic Design. Use when asking "what are the domains in this codebase?", "where should I draw service boundaries?", "identify bounded contexts", "classify subdomains", "DDD analysis", or analyzing domain cohesion. Do NOT use for grouping existing components into domains (use domain-identification-grouping) or dependency analysis (use coupling-analysis).
Groups existing components into logical business domains to plan service-based architecture. Use when asking "which components belong together?", "group these into services", "organize by domain", "component-to-domain mapping", or planning service extraction from an existing codebase. Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis).
AI frontend specialist and design consultant that guides users through a structured discovery process before generating any code. Collects visual references, design tokens, typography, icons, layout preferences, and brand guidelines to ensure the final output matches the user's vision with high fidelity. Use when the user asks to build, design, create, or improve any frontend interface — websites, landing pages, dashboards, components, apps, emails, forms, modals, or any UI element. Also triggers on "build me a UI", "design a page", "create a component", "improve this layout", "make this look better", "frontend", "interface", "redesign", or when the user provides mockups, screenshots, or design references. Do NOT use for backend logic, API design, database schemas, or non-visual code tasks.