How do I install the Domain Driven Design skill?

Run npx skillmds@latest add joaquimscosta/domain-driven-design in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Domain Driven Design safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Domain Driven Design?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Domain Driven Design free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Domain Driven Design?

joaquimscosta (@joaquimscosta) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Domain Driven Design by joaquimscosta

Name: Domain Driven Design
Author: joaquimscosta

Domain Driven Design

Expert guidance for Domain-Driven Design architecture and implementation. Use when designing complex business systems, defining bounded contexts, structuring domain models, choosing between modular monolith vs microservices, implementing aggregates/entities/value objects, or when users mention "DDD", "domain-driven design", "bounded context", "aggregate", "domain model", "ubiquitous language", "event storming", "context mapping", "domain events", "anemic domain model", strategic design, tactical patterns, or domain modeling. Helps make architectural decisions, identify subdomains, design aggregates, and avoid common DDD pitfalls.

joaquimscosta Updated Sep 21, 2026

File contents

Domain-Driven Design Skill

DDD manages complexity through alignment between software and business reality. Strategic design (boundaries, language, subdomains) provides more value than tactical patterns (aggregates, repositories).

When to Apply DDD

Apply DDD when:

Domain has intricate business rules
System is long-lived and high-value
Domain experts are available
Multiple teams/departments involved
Software represents competitive advantage

DDD is overkill when:

Simple CRUD applications
Tight deadlines, limited budgets
No domain experts available
Complexity is purely technical, not business

Core Workflow

Domain Discovery → 2. Bounded Context Definition → 3. Context Mapping → 4. Architecture Selection → 5. Tactical Implementation

See WORKFLOW.md for detailed step-by-step instructions for each phase.

Quick Reference

Subdomain Types (Problem Space)

Type	Investment	Example
Core	Maximum - competitive advantage	Recommendation engine, trading logic
Supporting	Custom but quality tradeoffs OK	Inventory management
Generic	Buy/outsource	Auth, email, payments

Key Decision: Entity vs Value Object

Entity: Has identity, tracked through time, mutable → Customer, Order
Value Object: Defined by attributes, immutable, interchangeable → Money, Address, Email

Default to value objects. Only use entities when identity matters.

Aggregate Design Rules (Vaughn Vernon)

Model true invariants in consistency boundaries
Design small aggregates (~70% should be root + value objects only)
Reference other aggregates by ID only
Use eventual consistency outside the boundary

Architecture Decision

Start with modular monolith when:
├── Team < 20 developers
├── Domain boundaries unclear
├── Time-to-market critical
└── Strong consistency required

Consider microservices when:
├── Bounded contexts have distinct languages
├── Teams can own full contexts
├── Independent scaling required
└── DevOps maturity exists

Detailed References

Strategic Patterns: See references/STRATEGIC-PATTERNS.md for subdomains, bounded contexts, context mapping, event storming
Tactical Patterns: See references/TACTICAL-PATTERNS.md for entities, value objects, aggregates, services, repositories
Architecture Alignment: See references/ARCHITECTURE-ALIGNMENT.md for clean/hexagonal architecture, modular monolith, microservices
Workflow: See WORKFLOW.md for detailed step-by-step DDD implementation process
Anti-Patterns: See references/ANTI-PATTERNS.md for common pitfalls and how to avoid them
Examples: See EXAMPLES.md for scenario walkthroughs applying DDD concepts
Troubleshooting: See TROUBLESHOOTING.md for common issues and solutions

Critical Reminders

Ubiquitous language first - Code should read like business language
Strategic before tactical - Understand boundaries before implementing patterns
Apply tactical patterns selectively - Only in core domains where complexity warrants
One aggregate per transaction - Cross-aggregate consistency via domain events
Persistence ignorance - Domain layer has no infrastructure dependencies

Related Skills

Need	Skill
Data layer implementation	`spring-boot-data-ddd` — JPA/JDBC aggregates, repositories, transactions
REST API layer	`spring-boot-web-api` — Controllers, validation, exception handling
Module boundaries	`spring-boot-modulith` — Module structure, event-driven communication
Testing patterns	`spring-boot-testing` — Aggregate tests, module tests, Scenario API
Security for domains	`spring-boot-security` — Method-level authorization, role-based access

---name: domain-driven-designdescription: Expert guidance for Domain-Driven Design architecture and implementation. Use when designing complex business systems, defining bounded contexts, structuring domain models, choosing between modular monolith vs microservices, implementing aggregates/entities/value objects, or when users mention "DDD", "domain-driven design", "bounded context", "aggregate", "domain model", "ubiquitous language", "event storming", "context mapping", "domain events", "anemic domain model", strategic design, tactical patterns, or domain modeling. Helps make architectural decisions, identify subdomains, design aggregates, and avoid common DDD pitfalls.---# Domain-Driven Design SkillDDD manages complexity through alignment between software and business reality. **Strategic design (boundaries, language, subdomains) provides more value than tactical patterns (aggregates, repositories).**## When to Apply DDD**Apply DDD when:**- Domain has intricate business rules- System is long-lived and high-value- Domain experts are available- Multiple teams/departments involved- Software represents competitive advantage**DDD is overkill when:**- Simple CRUD applications- Tight deadlines, limited budgets- No domain experts available- Complexity is purely technical, not business## Core Workflow1. Domain Discovery → 2. Bounded Context Definition → 3. Context Mapping → 4. Architecture Selection → 5. Tactical ImplementationSee [WORKFLOW.md](WORKFLOW.md) for detailed step-by-step instructions for each phase.## Quick Reference### Subdomain Types (Problem Space)| Type | Investment | Example ||------|-----------|---------|| **Core** | Maximum - competitive advantage | Recommendation engine, trading logic || **Supporting** | Custom but quality tradeoffs OK | Inventory management || **Generic** | Buy/outsource | Auth, email, payments |### Key Decision: Entity vs Value Object- **Entity**: Has identity, tracked through time, mutable → `Customer`, `Order`- **Value Object**: Defined by attributes, immutable, interchangeable → `Money`, `Address`, `Email`**Default to value objects.** Only use entities when identity matters.### Aggregate Design Rules (Vaughn Vernon)1. Model true invariants in consistency boundaries2. Design small aggregates (~70% should be root + value objects only)3. Reference other aggregates by ID only4. Use eventual consistency outside the boundary### Architecture Decision```Start with modular monolith when:├── Team < 20 developers├── Domain boundaries unclear├── Time-to-market critical└── Strong consistency requiredConsider microservices when:├── Bounded contexts have distinct languages├── Teams can own full contexts├── Independent scaling required└── DevOps maturity exists```## Detailed References- **Strategic Patterns**: See [references/STRATEGIC-PATTERNS.md](references/STRATEGIC-PATTERNS.md) for subdomains, bounded contexts, context mapping, event storming- **Tactical Patterns**: See [references/TACTICAL-PATTERNS.md](references/TACTICAL-PATTERNS.md) for entities, value objects, aggregates, services, repositories- **Architecture Alignment**: See [references/ARCHITECTURE-ALIGNMENT.md](references/ARCHITECTURE-ALIGNMENT.md) for clean/hexagonal architecture, modular monolith, microservices- **Workflow**: See [WORKFLOW.md](WORKFLOW.md) for detailed step-by-step DDD implementation process- **Anti-Patterns**: See [references/ANTI-PATTERNS.md](references/ANTI-PATTERNS.md) for common pitfalls and how to avoid them- **Examples**: See [EXAMPLES.md](EXAMPLES.md) for scenario walkthroughs applying DDD concepts- **Troubleshooting**: See [TROUBLESHOOTING.md](TROUBLESHOOTING.md) for common issues and solutions## Critical Reminders1. **Ubiquitous language first** - Code should read like business language2. **Strategic before tactical** - Understand boundaries before implementing patterns3. **Apply tactical patterns selectively** - Only in core domains where complexity warrants4. **One aggregate per transaction** - Cross-aggregate consistency via domain events5. **Persistence ignorance** - Domain layer has no infrastructure dependencies## Related Skills| Need | Skill ||------|-------|| Data layer implementation | `spring-boot-data-ddd` — JPA/JDBC aggregates, repositories, transactions || REST API layer | `spring-boot-web-api` — Controllers, validation, exception handling || Module boundaries | `spring-boot-modulith` — Module structure, event-driven communication || Testing patterns | `spring-boot-testing` — Aggregate tests, module tests, Scenario API || Security for domains | `spring-boot-security` — Method-level authorization, role-based access |

Frequently asked questions