Agent Skills: Domain-Driven Design

Domain-Driven Design reference for strategic and tactical modeling. Use when user says "model this domain", "design a bounded context", "create an aggregate", "what's a value object", "apply DDD", or asks about ubiquitous language, context mapping, entities, repositories, domain events, or aggregates. Do NOT use for infrastructure/DevOps, pure UI components, or simple CRUD without business rules.

UncategorizedID: bikach/skills-claude-code/domain-driven-design

Install this agent skill to your local

pnpm dlx add-skill https://github.com/Bikach/skills-claude-code/tree/HEAD/domain-driven-design

Skill Files

Browse the full folder contents for domain-driven-design.

Download Skill

Loading file tree…

domain-driven-design/SKILL.md

Skill Metadata

Name
domain-driven-design
Description
Domain-Driven Design reference for strategic and tactical modeling. Use when user says "model this domain", "design a bounded context", "create an aggregate", "what's a value object", "apply DDD", or asks about ubiquitous language, context mapping, entities, repositories, domain events, or aggregates. Do NOT use for infrastructure/DevOps, pure UI components, or simple CRUD without business rules.

Domain-Driven Design

Reference for applying Domain-Driven Design, split into strategic design (high-level domain decomposition) and tactical design (building blocks inside a bounded context).

This skill uses progressive disclosure: read the relevant pattern file on demand instead of loading everything at once.

When to Use This Skill

  • Modeling a new domain or refactoring an existing one
  • Deciding where boundaries belong (bounded contexts, subdomains)
  • Choosing the right tactical building block (entity vs value object vs aggregate)
  • Establishing a shared vocabulary with the business (ubiquitous language)
  • Designing repositories, domain events, factories, or domain services

Do NOT use for infrastructure/DevOps tasks, pure UI work, or anemic CRUD with no business invariants.

Workflow

  1. Start strategic. Clarify the domain, subdomains, and bounded contexts before writing any code. Establish the ubiquitous language first.
  2. Map relationships between contexts (partnership, conformist, anti-corruption layer, ...).
  3. Then go tactical inside a single bounded context: model aggregates, entities, value objects, and the rules that protect invariants.
  4. Keep the language consistent between code and the strategic model at all times.

Strategic Design

High-level decomposition of the problem space.

| Pattern | File | Use for | |---|---|---| | Ubiquitous Language | strategic/ubiquitous-language.md | Shared vocabulary between business and code | | Subdomain Classification | strategic/subdomain-classification.md | Core / supporting / generic subdomains | | Bounded Context | strategic/bounded-context.md | Defining explicit model boundaries | | Context Mapping | strategic/context-mapping.md | Relationships & integration between contexts |

Tactical Design

Building blocks inside a bounded context.

| Pattern | File | Use for | |---|---|---| | Entity | tactical/entity.md | Objects with identity and lifecycle | | Value Object | tactical/value-object.md | Immutable, identity-less concepts | | Aggregate | tactical/aggregate.md | Consistency boundaries & invariants | | Domain Event | tactical/domain-event.md | Something meaningful that happened | | Repository | tactical/repository.md | Persistence abstraction for aggregates | | Factory | tactical/factory.md | Complex object/aggregate creation | | Domain Service | tactical/domain-service.md | Stateless domain logic spanning entities | | Specification | tactical/specification.md | Reusable business rule / query predicate |

Related Skills

  • [[architecting-backend]] — hexagonal architecture, SOLID, where DDD building blocks fit
  • [[security-guardian]] — validating invariants and inputs at domain boundaries