Domain-Driven Design
Modeling complex business domains in software
Model complex business domains in software using Eric Evans's Domain-Driven Design methodology. This skill equips your AI agent with ubiquitous language, bounded contexts, aggregates, and strategic design patterns for tackling the most complex software challenges.
npx skills add wondelai/skills/domain-driven-design --global 
Domain-Driven Design Eric Evans View on Amazon
02 What it is
What is the Domain-Driven Design skill?
The Domain-Driven Design skill packages Eric Evans’s book as a free set of instructions your AI coding agent loads on demand. It makes the agent model the business first — build a ubiquitous language, split the system into bounded contexts, design aggregates that own their invariants — so the code names and enforces what the domain actually means.
03 Key concepts
Five principles your agent applies.
Drawn from Domain-Driven Design — not advice it repeats back to you, but decisions it makes while it works.
04 Fit
When to use it, and
when not to.
four symptoms it fixes, and four it doesn't.
Reach for it when
Your team and your code use different words for the same thing, and translating between them keeps producing bugs.
One Customer class has grown forty fields because billing, support and marketing each needed three of them.
Entities are passive data bags and every business rule lives in a service class nobody can locate.
You need to decide where one module ends and the next begins, and the org chart is your only guide.
Reach for something else when
The domain is genuinely simple CRUD and the modelling would be ceremony. The 37signals Way’s build-less instinct fits better.
You have the model and need to know which way dependencies cross its boundaries. that is Clean Architecture.
The hard part is persistence, replication and consistency rather than the model. Data-Intensive Apps covers that.
You are untangling an existing untested codebase before you can model anything. start with Legacy Code.
05 Prompts
Say it like this.
Name the skill at the end of a prompt and the agent applies the framework rather than a vibe. Or say nothing — it loads on its own when a task matches.
Define bounded contexts and a context map for our e-commerce platform using domain-driven-design skill
Design aggregates for this order management domain using domain-driven-design skill
Establish a ubiquitous language glossary for our billing domain using domain-driven-design skill
Implement an anti-corruption layer between our legacy system and new service using domain-driven-design skill
06 About the author
07 Same stack
The stack it sits in.
Six Architecture & Systems skills. Most people run two: this one, and whichever fits the next problem.
All Architecture & Systems skills08 Questions
Before you install.
How do I install the Domain-Driven Design skill?
Run npx skills add wondelai/skills/domain-driven-design --global. It takes about 30 seconds and needs no account. The Domain-Driven Design skill then works in Claude, Claude Code, Claude Cowork, Codex, Cursor, OpenClaw and Hermes Agent — anything that reads the open agentskills.io format — and your agent loads it on its own when a task calls for it. It is free and MIT-licensed, and the source is at https://github.com/wondelai/skills.
Which book is the Domain-Driven Design skill based on?
It packages Domain-Driven Design by Eric Evans — originator of Domain-Driven Design. The skill distils the book's method into instructions your agent follows while it works, covering ubiquitous language, bounded contexts and aggregates. It sits in the Architecture & Systems part of the library.
What is a bounded context, concretely?
A boundary inside which one word has exactly one meaning and one model. Customer in billing has a tax ID and a payment method; Customer in support has a ticket history and a satisfaction score. Those are different models, and fusing them into a single omniscient class is the failure the pattern exists to prevent. Contexts are also where integration becomes explicit — you translate at the border, often through an anti-corruption layer.
How does this differ from Clean Architecture and Software Design?
Three different questions about the same code. Domain-Driven Design asks what the business means and where its seams are. Clean Architecture asks which way dependencies cross those seams. Software Design asks whether the resulting modules are deep enough to justify their interfaces. They rarely contradict each other; when they do, it is usually a pile of small value objects against Ousterhout’s warning about shallow modules, and you decide case by case.
Do I need to read the book? It is famously long.
No. The skill carries the operational parts: how to build a ubiquitous language, how to locate context boundaries, the aggregate rules it applies — keep them small, one root, reference other aggregates by ID — and the context-mapping patterns. The book’s several hundred pages are largely worked narrative showing how those conclusions were reached, which is worth reading and is not required to apply them.
Will it apply full DDD to a simple CRUD app?
It will if you ask, and that is usually a bad trade. Aggregates, repositories, domain events and a separate application layer buy very little when the domain is a form saved to a table, and the ceremony is real. The skill’s own strategic-design step is the guard: classify subdomains as core, supporting or generic, and model only the core deeply. If nothing is core, you probably do not need this.
09 Guides that use it
Put it to work.
Long-form playbooks where this skill does part of the job.
One skill, one command.
Install Domain-Driven Design, or the whole stack.
npx skills add wondelai/skills/domain-driven-design --global MIT licensed · Claude, Claude Code, Codex, Cursor, OpenClaw, Hermes · No account