# Plan Domain-Driven Design Work

Complex domains need clear boundaries before implementation patterns are selected. This skill assesses DDD viability, defines strategic artifacts, and recommends focused next steps.

## Install

```bash
npx skillstore add sickn33/domain-driven-design
```

## Metadata

- Status: approved
- Slug: sickn33-domain-driven-design
- Skillstore revision: r2
- Version status: missing
- Tree hash: 3d6b3968a928333272ecb8a36efbb70822f2110560f89c31f54cc2e404f3bf09
- Author: sickn33
- GitHub username: sickn33
- License: MIT
- Repository: https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/domain-driven-design
- Ref: f9e2c34b4f19c7f3e6b0a1e93227b5f77cc12526
- Supported tools: Claude, Codex, Claude Code
- Audit status: complete
- Agent install advisory: allowed
- Manual install advisory: allowed
- Artifact signature: available
- Audit attestation: unavailable
- Human verification: not\_verified
- Risk factors: external\_commands
- Quality score: 74
- Public page: https://skillstore.pages.dev/skills/sickn33-domain-driven-design
- Manifest: https://skillstore.pages.dev/api/skills/sickn33-domain-driven-design/manifest

## Capabilities

- Assesses DDD viability using business complexity, team collisions, unstable integrations, and auditability.
- Prioritizes subdomain maps, bounded contexts, and a shared language glossary.
- Routes strategic, tactical, CQRS, event sourcing, saga, projection, and decision-record tasks.
- Defines scope, assumptions, produced artifacts, open risks, and a recommended next step.
- Provides checklists for strategic, tactical, and evented architecture deliverables.

## Use Cases

- Assess DDD Adoption: Evaluate whether a complex product domain justifies full DDD before committing engineering resources.
- Define Service Boundaries: Map subdomains, bounded contexts, ownership, and shared language for teams with overlapping models.
- Plan Evented Architecture: Connect domain needs to CQRS, event sourcing, sagas, projections, and required governance artifacts.

## Prompt Templates

### Check DDD Viability

```
Assess whether {system} needs full DDD. List assumptions, applicable viability criteria, risks, and the next recommended step.
```

### Map the Domain

```
Create a strategic DDD plan for {domain}. Identify subdomains, bounded contexts, ownership questions, glossary terms, and missing domain knowledge.
```

### Choose Tactical Patterns

```
Given {context_description}, recommend aggregates, invariants, value objects, domain events, repository contracts, and transaction boundaries. Explain unresolved risks.
```

### Plan Evented Delivery

```
Evaluate CQRS and event sourcing for {system}. Define justification, schema versioning, saga compensation, projection rebuilding, evidence, and specialist routing.
```

## Limitations

- Does not replace workshops with domain experts or product representatives.
- Does not generate framework-specific implementation code.
- Depends on separately available skills for specialized implementation guidance.
- Should not be used for simple CRUD systems with low business complexity.

## Best Practices

- Run the viability check before adopting full DDD.
- Complete strategic artifacts before selecting tactical or evented patterns.
- Record assumptions, evidence, open risks, and measurable success criteria.

## Anti Patterns

- Do not adopt DDD only because the architecture is fashionable.
- Do not define aggregates before bounded contexts and language are understood.
- Do not plan event sourcing without versioning, compensation, and rebuild strategies.

## Security Audit

- Audited at: 2026-07-23T22:52:37.148\+00:00
- Summary: All ten static findings are false positives caused by Markdown backticks around skill names, a local reference path, and a plain-text example. The reviewed files contain no executable commands or semantic security concerns.

## Stats

- Views: 122
- Downloads: 13
- Favorites: 1
- Popularity score: 0