---
name: domain-driven-design
description: >-
  A library of 62 nested Domain-Driven Design pattern skills covering strategic and tactical DDD:
  Ubiquitous Language, Bounded Contexts, Aggregates, context mapping, architecture styles, supple
  design, and distillation. Use when modeling a domain, choosing microservice or bounded-context
  boundaries, integrating legacy systems, reviewing code against Evans or Vernon, designing with
  domain experts, or picking which DDD pattern applies.
metadata:
  ddd.category: root
  ddd.sources: "Evans; Vernon"
---

# Domain-Driven Design

<EXTREMELY-IMPORTANT>
If you think there is even a 1% chance a named DDD pattern applies to what you are about to
implement, review, choose, or co-design, you ABSOLUTELY MUST load that pattern's own SKILL.md and
follow it. Knowing the concept is not the same as loading the skill — patterns have specific
P-rules, checks, and gotchas drawn from Evans and Vernon that general knowledge misses.
</EXTREMELY-IMPORTANT>

This is the entry point for a library of 62 DDD pattern skills grounded in Evans, *Domain-Driven
Design* (2003), and Vernon, *Implementing Domain-Driven Design* (2013), plus two facilitation
hubs. Every pattern skill is nested under this one at `patterns/<name>/SKILL.md`; the two hubs are
sibling skills loaded by name, not nested. **The rule:** before implementing, reviewing, choosing,
or co-designing anything a DDD pattern covers — an aggregate boundary, a bounded context, a
context-map relationship, an architecture style, a tactical building block — load the matching
pattern skill from the index below and follow it. Do not reason about a named DDD pattern from
memory alone.

## Routing

| Situation | Load |
|---|---|
| Don't know which pattern(s) apply; assessing an existing codebase or scenario cold | `ddd-selecting-patterns` |
| Running a live, turn-by-turn design conversation with a human from scratch | `ddd-collaborative-design` |
| The task already names a pattern, or its symptoms (e.g. "review our aggregate", "two teams keep stepping on each other's model") | Go straight to that pattern skill in the index below |
| Unsure DDD is warranted at all for this system | See "Is DDD warranted?" below, then `ddd-selecting-patterns` |

Both hubs are themselves full pattern-shaped skills (P-rules, checks, verdict block, first-reply
contract) — load the hub's own SKILL.md rather than re-deriving its routing logic here.

## Is DDD warranted at all?

Not every system needs tactical DDD. A small, short-lived, single-team tool with no domain
experts to learn from is a legitimate candidate for the Smart UI "anti-pattern" instead —
`ddd-smart-ui-anti-pattern` covers when that trade-off is sound. A cohesive piece of the domain
that is necessary but not differentiating (standard accounting, address validation, time zones) is
a Generic Subdomain, not a Core Domain — `ddd-generic-subdomain` covers buying, publishing, or
outsourcing it instead of building it bespoke. If it's unclear which of "skip DDD," "generic,
minimal DDD," or "full tactical DDD" fits, start at `ddd-selecting-patterns` — it classifies
subdomains first and routes everything else from that classification.

## Index

Names resolve relative to this file: every name below lives at `patterns/<name>/SKILL.md` unless
marked "(hub, sibling)". Cross-references anywhere in this library use these names exactly.

### Practice — modeling process, language, and insight

| Name | Path | Trigger |
|---|---|---|
| ddd-ubiquitous-language | patterns/ddd-ubiquitous-language/SKILL.md | Naming, glossaries, terminology drift, conflicting word meanings across teams |
| ddd-knowledge-crunching | patterns/ddd-knowledge-crunching/SKILL.md | Distilling domain-expert knowledge into a deep model; hidden rules becoming explicit |
| ddd-model-driven-design | patterns/ddd-model-driven-design/SKILL.md | Code mapping directly to one model; shadow models; mixed-paradigm tooling |
| ddd-hands-on-modelers | patterns/ddd-hands-on-modelers/SKILL.md | Team structure; architect/developer separation; domain-expert liaison bottlenecks |
| ddd-refactoring-toward-deeper-insight | patterns/ddd-refactoring-toward-deeper-insight/SKILL.md | Model breakthrough; deep redesign; exploration teams; refactor timing |
| ddd-making-implicit-concepts-explicit | patterns/ddd-making-implicit-concepts-explicit/SKILL.md | Hidden rules, duplicated conditionals, a process that should be a domain object |
| ddd-analysis-patterns | patterns/ddd-analysis-patterns/SKILL.md | Adapting a documented domain-model fragment (ledgers, posting rules) as a starting point |

### Architecture — system structure around the model

| Name | Path | Trigger |
|---|---|---|
| ddd-layered-architecture | patterns/ddd-layered-architecture/SKILL.md | Layer boundaries, dependency direction, Dependency Inversion, anemic application layers |
| ddd-smart-ui-anti-pattern | patterns/ddd-smart-ui-anti-pattern/SKILL.md | Judging whether a simple/short-lived app can skip a layered domain model |
| ddd-hexagonal-architecture | patterns/ddd-hexagonal-architecture/SKILL.md | Multiple client types, swappable persistence/messaging, infra-free testing |
| ddd-service-oriented-architecture | patterns/ddd-service-oriented-architecture/SKILL.md | Mapping Bounded Contexts to technical services without collapsing models |
| ddd-rest-architecture | patterns/ddd-rest-architecture/SKILL.md | RESTful HTTP APIs, resource/URI design, HTTP verb semantics, HATEOAS |
| ddd-event-driven-architecture | patterns/ddd-event-driven-architecture/SKILL.md | Async messaging, event pipelines, at-least-once delivery, correlation/idempotency |
| ddd-cqrs | patterns/ddd-cqrs/SKILL.md | Read/write split, cross-aggregate dashboards, use-case-optimal read models |
| ddd-event-sourcing | patterns/ddd-event-sourcing/SKILL.md | Event-sourced persistence, Event Stores, concurrency control, snapshots |

### Tactical — building blocks inside a Bounded Context

| Name | Path | Trigger |
|---|---|---|
| ddd-entity | patterns/ddd-entity/SKILL.md | Object identity, identity generation, equals/hashCode, Entity vs Value Object |
| ddd-value-object | patterns/ddd-value-object/SKILL.md | Immutable types, value equality, mutation vs replacement, persisting values |
| ddd-associations | patterns/ddd-associations/SKILL.md | Object references, collections, traversal direction, back-references |
| ddd-domain-service | patterns/ddd-domain-service/SKILL.md | A standalone domain operation with no natural home on one Entity or Value Object |
| ddd-module | patterns/ddd-module/SKILL.md | Package/folder structure; modules vs layers vs Bounded Contexts |
| ddd-application-services | patterns/ddd-application-services/SKILL.md | Use-case entry points, orchestration, DTOs, application/domain/infra split |
| ddd-aggregate | patterns/ddd-aggregate/SKILL.md | Aggregate boundaries, roots, invariants, concurrency conflicts, cross-aggregate refs |
| ddd-factory | patterns/ddd-factory/SKILL.md | Complex object/Aggregate creation, reconstitution, Factory Method placement |
| ddd-repository | patterns/ddd-repository/SKILL.md | Data access, collection- vs persistence-oriented design, Repository vs DAO |
| ddd-specification | patterns/ddd-specification/SKILL.md | Reusable business-rule predicates for validation, selection, or query filters |
| ddd-policy-strategy | patterns/ddd-policy-strategy/SKILL.md | Interchangeable ranking/pricing/routing rules factored out of a process |
| ddd-composite-domain | patterns/ddd-composite-domain/SKILL.md | Recursive trees, uniform part/whole node operations, Composite vs Flyweight |

### Supple design — making the domain model safe and expressive to use

| Name | Path | Trigger |
|---|---|---|
| ddd-supple-design | patterns/ddd-supple-design/SKILL.md | Deciding which supple-design technique to invest in for a hard-to-use model |
| ddd-intention-revealing-interfaces | patterns/ddd-intention-revealing-interfaces/SKILL.md | Names that hide side effects or over-reveal implementation mechanics |
| ddd-side-effect-free-functions | patterns/ddd-side-effect-free-functions/SKILL.md | Mixed calculation/mutation, hidden argument mutation, unsafe previews |
| ddd-assertions | patterns/ddd-assertions/SKILL.md | Unenforced invariants, ambiguous argument effects, awkward postconditions |
| ddd-conceptual-contours | patterns/ddd-conceptual-contours/SKILL.md | Class/method granularity; decomposition that doesn't follow domain axes |
| ddd-standalone-classes | patterns/ddd-standalone-classes/SKILL.md | Reducing dependencies for testability of intricate domain computations |
| ddd-closure-of-operations | patterns/ddd-closure-of-operations/SKILL.md | Combine/merge/add methods whose result type should match their argument |

### Integration — crossing Bounded Context boundaries at runtime

| Name | Path | Trigger |
|---|---|---|
| ddd-domain-events | patterns/ddd-domain-events/SKILL.md | Event shape, publishers/subscribers, event identity, spreading events remotely |
| ddd-long-running-processes | patterns/ddd-long-running-processes/SKILL.md | Sagas, process managers, trackers, step time-outs across Aggregates/services |
| ddd-bounded-context-integration | patterns/ddd-bounded-context-integration/SKILL.md | Cross-service contracts, de-duplication, handling downstream unavailability |

### Strategic — sizing and classifying the model itself

| Name | Path | Trigger |
|---|---|---|
| ddd-subdomains | patterns/ddd-subdomains/SKILL.md | Classifying business areas as Core, Supporting, or Generic before anything else |
| ddd-bounded-context | patterns/ddd-bounded-context/SKILL.md | Context boundaries, model splinters, microservice/module boundary decisions |
| ddd-continuous-integration | patterns/ddd-continuous-integration/SKILL.md | Merge cadence, model-drift incidents, duplicate concepts inside one context |
| ddd-context-map | patterns/ddd-context-map/SKILL.md | Documenting the integration landscape; upstream/downstream roles |

### Context relationship — naming how two contexts relate organizationally

| Name | Path | Trigger |
|---|---|---|
| ddd-shared-kernel | patterns/ddd-shared-kernel/SKILL.md | Two teams jointly owning a small, explicit shared module |
| ddd-customer-supplier | patterns/ddd-customer-supplier/SKILL.md | Upstream team negotiates priorities and acceptance tests with a downstream team |
| ddd-conformist | patterns/ddd-conformist/SKILL.md | Downstream adopts a non-negotiable upstream's model as-is, no translation |
| ddd-partnership | patterns/ddd-partnership/SKILL.md | Two teams whose features mutually depend, coordinating planning and releases |
| ddd-anticorruption-layer | patterns/ddd-anticorruption-layer/SKILL.md | Translating a legacy or external model at the boundary so it can't leak in |
| ddd-separate-ways | patterns/ddd-separate-ways/SKILL.md | Deciding two contexts have no integration because the cost outweighs the benefit |
| ddd-open-host-service | patterns/ddd-open-host-service/SKILL.md | One team serving a stable, use-case-shaped API to many consumer teams |
| ddd-published-language | patterns/ddd-published-language/SKILL.md | A documented, standards-based interchange format between contexts |
| ddd-big-ball-of-mud | patterns/ddd-big-ball-of-mud/SKILL.md | Bounding a legacy system with mixed models as one opaque Context on a map |

### Distillation — surfacing and protecting the Core Domain

| Name | Path | Trigger |
|---|---|---|
| ddd-core-domain | patterns/ddd-core-domain/SKILL.md | Staffing, build-vs-buy, refactor priority driven by business differentiation |
| ddd-generic-subdomain | patterns/ddd-generic-subdomain/SKILL.md | Deciding to buy, publish, outsource, or build a non-differentiating part |
| ddd-domain-vision-statement | patterns/ddd-domain-vision-statement/SKILL.md | A short nontechnical statement of the core domain and its value |
| ddd-highlighted-core | patterns/ddd-highlighted-core/SKILL.md | Lightweight distillation document or flagged markers without restructuring |
| ddd-cohesive-mechanism | patterns/ddd-cohesive-mechanism/SKILL.md | Extracting an algorithm/rule engine out of the Core so it states "what" |
| ddd-segregated-core | patterns/ddd-segregated-core/SKILL.md | Physically separating Core classes from entangling generic/supporting code |
| ddd-abstract-core | patterns/ddd-abstract-core/SKILL.md | Distilling deep, shared abstractions out of several specialized Modules |

### Large-scale structure — optional system-wide organizing patterns

| Name | Path | Trigger |
|---|---|---|
| ddd-evolving-order | patterns/ddd-evolving-order/SKILL.md | Choosing how restrictive a structure should be and how it evolves |
| ddd-system-metaphor | patterns/ddd-system-metaphor/SKILL.md | An XP-style concrete analogy guiding design and the Ubiquitous Language |
| ddd-responsibility-layers | patterns/ddd-responsibility-layers/SKILL.md | Stratifying a model into broad named responsibility layers |
| ddd-knowledge-level | patterns/ddd-knowledge-level/SKILL.md | Configurable role hierarchies, approval chains, type-driven business rules |
| ddd-pluggable-component-framework | patterns/ddd-pluggable-component-framework/SKILL.md | Multi-vendor plug-in architectures around a mature, distilled abstract core |

### Hubs (sibling skills, not nested under patterns/)

| Name | Path | Trigger |
|---|---|---|
| ddd-selecting-patterns | skills/ddd-selecting-patterns/SKILL.md | Picking which pattern(s) fit an already-scoped codebase or scenario |
| ddd-collaborative-design | skills/ddd-collaborative-design/SKILL.md | Running a full strategic-to-tactical design conversation with a human |

## Conventions

- Every name above is resolved through this index, relative to this file; a reference elsewhere in
  the library to e.g. `ddd-aggregate` means `patterns/ddd-aggregate/SKILL.md` here.
- Every pattern skill carries the same shape: numbered P-rules, a C-numbered review checklist, the
  same `Verdict: CONFORMS | PARTIAL | VIOLATES | NOT APPLICABLE` block, and a "Designing with a
  human" section opening with a first-reply contract. Don't improvise a different report format.
- Pattern skills load their own `references/` files only when their own SKILL.md tells you to
  (e.g. "load `references/implementation.md` for the worked example") — don't pre-load references
  speculatively from here.
- This root file only routes; it never re-teaches a pattern's rules. If you find yourself writing
  P-rule-shaped guidance here, it belongs in the pattern skill instead.

## Red flags

These thoughts mean stop and load the pattern skill instead of proceeding from memory:

| Thought | Reality |
|---|---|
| "I know what an aggregate/bounded context is" | Knowing the concept isn't the same as the skill's specific P-rules and checks; load it. |
| "This is just a quick code review, not a full design" | `Verify` mode is still governed by the skill's checklist; load it before judging. |
| "The user only asked for code, not a pattern discussion" | Implementing is exactly when the skill's P-rules and gotchas prevent the common misapplication. |
| "This pattern obviously doesn't apply here" | That's a selection judgment `ddd-selecting-patterns` is built to make explicit, not skip silently. |
| "I'll just pick the pattern that sounds closest" | Near-miss patterns (e.g. Conformist vs Customer/Supplier) are exactly where the index's trigger and the skill's "When to use" diverge from guesswork. |
| "There's no time to read another file" | Pattern SKILL.md bodies are short by design; skipping it risks a wrong boundary that costs far more to unwind later. |
| "The hub already covers this" | Hubs route and facilitate; they explicitly hand off tactical/structural detail to the named pattern skill — follow the handoff. |
| "I already loaded a similar pattern earlier in this session" | Adjacent patterns (e.g. Entity vs Value Object, Shared Kernel vs Conformist) have different, sometimes conflicting rules; load the one that actually matches. |