# Domain-Driven Design > Modeling complex business domains in software — an AI agent skill based on *Domain-Driven Design* by Eric Evans. Published 2026-02-23 · Updated 2026-08-17 · Architecture & Systems · Free and MIT-licensed Canonical: https://skills.wondel.ai/skills/domain-driven-design/ Source: https://github.com/wondelai/skills/tree/main/domain-driven-design **Install:** `npx skills add wondelai/skills/domain-driven-design --global` ## 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. ## Key concepts from Domain-Driven Design your agent applies - **Ubiquitous Language** — Develop a shared language between developers and domain experts — use it in code, conversations, and documentation. - **Bounded Contexts** — Define clear boundaries where a particular model applies. Different contexts can have different models for the same concept. - **Aggregates** — Cluster related entities and value objects into consistency boundaries with a single root entity controlling access. - **Domain Events** — Capture things that happen in the domain as first-class objects — events enable loose coupling between bounded contexts. - **Context Mapping** — Map relationships between bounded contexts — shared kernel, customer-supplier, conformist, anti-corruption layer. ## When to use Domain-Driven Design — and when not to 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. ## About Eric Evans Originator of Domain-Driven Design. Eric Evans is a software design consultant and the originator of Domain-Driven Design. His book, published in 2003, fundamentally changed how the industry approaches complex software by putting the domain model at the center of development. The book: https://openlibrary.org/books/OL51275329M/Domain-Driven_Design ## Example prompts - Define bounded contexts and a context map for our e-commerce platform using domain-driven-design skill _(Strategic design)_ - Design aggregates for this order management domain using domain-driven-design skill _(Tactical design)_ - Establish a ubiquitous language glossary for our billing domain using domain-driven-design skill _(Domain modeling)_ - Implement an anti-corruption layer between our legacy system and new service using domain-driven-design skill _(Integration)_ ## Frequently asked questions ### 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. ## Related - All Architecture & Systems skills: https://skills.wondel.ai/skills/architecture/ - Clean Architecture: https://skills.wondel.ai/skills/clean-architecture/ - Data-Intensive Apps: https://skills.wondel.ai/skills/ddia-systems/ - System Design: https://skills.wondel.ai/skills/system-design/ - Release It!: https://skills.wondel.ai/skills/release-it/ - High Perf Browser: https://skills.wondel.ai/skills/high-perf-browser/