---
name: ddd-selecting-patterns
description: >-
  Selecting Patterns hub for Domain-Driven Design: picks which DDD skills apply and in what order,
  strategic-first from subdomain classification through context relationships to tactical patterns.
  Use when implementing, reviewing, choosing, or co-designing which pattern fits, auditing a
  selection plan, or routing to core-domain and tactical skills.
metadata:
  ddd.category: hub
  ddd.sources: "Evans ch. 17, Appendix, Part IV intro, ch. 14, ch. 15; Vernon Guide, ch. 1-3"
---

# Selecting Patterns

Selecting Patterns is the router across the other DDD skills: given a codebase or scenario, it
decides which Subdomain classification, Bounded Context, context-relationship, architecture, and
tactical patterns actually apply, and in what order. The core principle is strategic-first: classify
before you integrate, integrate before you architect, architect before you pick tactical building
blocks — never the reverse. Used well, this buys proportional investment (best effort where it
differentiates the business, least effort where it doesn't) and stops the two most expensive
mistakes: applying heavy DDD uniformly everywhere, and skipping it entirely where it would pay off.

## How to use this skill

| Mode | What to do | Which file to read and when |
|---|---|---|
| Implement | Produce a Pattern-Selection Record: classified subdomains, named context relationships, and an ordered list of skills to load next, per P1–P11 | Load `references/implementation.md` for the worked example, template, and tests |
| Verify | Review an existing architecture/pattern-selection document or facilitation transcript against every check in `references/review-checklist.md`; report in the verdict format | Always load the checklist before judging |
| Select | Use the signals table and decision flow below to decide which skill(s) this scenario actually needs | Read this file; it is itself the selection step for every other skill |
| Design with a human | Ask the ordered meta-questions under "Designing with a human" to route the conversation, then hand off to the named skill's own facilitation | Inline below (short) |

Pattern skills named here are nested in the `domain-driven-design` skill at
`patterns/<name>/SKILL.md`; resolve names through its index.

## Core rules

1. **P1 — Classify subdomains before anything else.** Before naming a Bounded Context, an architecture style, or a tactical pattern, classify each candidate area of the business as Core, Supporting, or Generic (`ddd-subdomains`). Every downstream decision depends on this classification; it never depends on them.
2. **P2 — Investment is proportional to classification, never uniform.** Core Domain gets the heaviest tactical investment (rich model, Aggregates, Domain Events, best talent); Supporting gets a correctness-first model without heavy ceremony; Generic gets the thinnest viable implementation, preferably bought, published, or outsourced.
3. **P3 — Problem space before solution space.** Finish classifying subdomains in business terms before naming Bounded Contexts, services, or architecture styles; don't let a technical boundary drive the classification.
4. **P4 — Bounded Contexts are sized by model divergence, not by technical unit.** Draw context boundaries where the Ubiquitous Language and model actually diverge, scaled to what one team can keep unified through Continuous Integration — not one per entity, table, or microservice by default.
5. **P5 — Every cross-context relationship gets an explicit, organizationally-justified context-map pattern.** Choose Shared Kernel, Customer/Supplier, Conformist, Partnership, Anticorruption Layer, Open Host Service + Published Language, or Separate Ways based on the real relationship between the teams or systems involved, never as a default or an afterthought.
6. **P6 — Architecture style is chosen after context boundaries, to serve each context's needs.** Pick Layered, Hexagonal, SOA, REST, Event-Driven, CQRS, or Event Sourcing per context based on that context's actual consistency, integration, and audit requirements; never mandate one style uniformly across every context.
7. **P7 — Tactical building blocks are scoped inside an already-settled Bounded Context, sized to its classification.** Aggregate, Domain Events, Repository, Specification, and the rest are applied once P1–P4 are settled, not designed first.
8. **P8 — Generic Subdomains and Smart-UI-appropriate systems skip heavy tactical DDD.** A Generic Subdomain gets the thinnest adequate model (buy/outsource/publish); a small, short-lived, single-team application may legitimately use the Smart UI "anti-pattern" instead of a layered domain model.
9. **P9 — Assessment comes first.** Before recommending any pattern, check the current Context Map (even an inconsistent one), the health of the Ubiquitous Language, whether a Core Domain is already identified, and the team's domain and technical skill — don't prescribe patterns cold.
10. **P10 — Not every system needs DDD.** If the domain is simple, short-lived, has no domain experts to learn from, or the team lacks the time/skill investment DDD requires, say so and recommend a lighter-weight approach instead of defaulting into full tactical DDD.
11. **P11 — Hand off by skill name; never re-teach the pattern.** This hub's output is a selection — which skill(s) to load, in what order, and why — not an inline implementation of any one pattern.

## When to use

**Signals it fits**
- A new initiative, brownfield modernization, or multi-context system needs to know which of the ~60 DDD skills actually apply, and in what order.
- A proposed architecture or pattern plan needs independent review for category errors (e.g., tactical investment not matching subdomain classification).
- A system spans multiple business capabilities with different competitive importance — some differentiate the business, some are plumbing.
- Someone asks "should we use Event Sourcing / CQRS / microservices / Shared Kernel here?" without having classified subdomains first.

**Signals it does not fit / over-engineering**
- The ask is already scoped to one named pattern ("review our Aggregate design") — go straight to that skill (e.g. `ddd-aggregate`), not through this hub.
- A live, turn-by-turn strategic-to-tactical design conversation with a human is wanted end to end — use `ddd-collaborative-design`; this hub produces a selection artifact, not an extended facilitation session.
- The question is purely tactical code review inside one already-well-bounded context — go directly to the relevant tactical skill.

**Alternatives** (prerequisite: none — this is usually the first skill consulted)
- `ddd-collaborative-design` — hub for facilitating the full strategic-to-tactical design conversation with a human, turn by turn, including combining large-scale structure, context, and distillation; use instead when the ask is "walk us through designing this" rather than "tell us which patterns apply."
- `ddd-subdomains` / `ddd-core-domain` / `ddd-generic-subdomain` — the classification step this hub always routes through first.
- `ddd-bounded-context` / `ddd-context-map` — the solution-space steps that follow classification.

## Implementing

1. Assess first: ask for or draw the current Context Map, check the Ubiquitous Language, and ask whether a Core Domain is already named (P9).
2. Classify every candidate subdomain as Core, Supporting, or Generic in business terms only, with a differentiation-based justification for Core (P1, P3).
3. Gauge whether DDD investment is warranted at all — small, simple, or short-lived systems may be better served by Smart UI / CRUD (P8, P10).
4. Draw or confirm Bounded Context boundaries where the model/language actually diverges, sized to what one team can keep unified (P4).
5. For each cross-context relationship, identify the real organizational relationship and assign the matching context-map pattern (P5), using the table below.
6. Choose an architecture style per context based on that context's own integration/consistency/audit needs (P6).
7. Scope tactical building blocks inside each context, sized to its classification (P2, P7).
8. Record the result as a Pattern-Selection Record: subdomain table, relationship table, architecture choices, and an ordered list of skill names to load next (P11).

```mermaid
flowchart TD
    A[Assess: context map, language, core, skill] --> B[Classify subdomains: core / supporting / generic]
    B --> C{DDD investment warranted?}
    C -- no, trivial/short-lived --> C1[ddd-smart-ui-anti-pattern]
    C -- yes --> D[Draw/confirm Bounded Contexts]
    D --> E[Assign context-map pattern per relationship]
    E --> F[Choose architecture style per context]
    F --> G[Scope tactical building blocks per context]
    G --> H[Record Pattern-Selection Record, hand off by skill name]
```

Signals-to-skill map (non-exhaustive; see `references/implementation.md` for the full table):

| Observation | Load |
|---|---|
| "This is what sets us apart / competitors can't replicate it" | `ddd-core-domain` |
| Standard accounting, payments, addresses, time zones — could be bought | `ddd-generic-subdomain` |
| Business-specific but not differentiating (e.g. vendor-feed import) | `ddd-subdomains` (Supporting) |
| Two teams willing to co-own code, integrate at least weekly | `ddd-shared-kernel` |
| Upstream team negotiates priorities with a downstream team | `ddd-customer-supplier` |
| Downstream has no influence over upstream, must accept it as-is | `ddd-conformist` |
| Legacy or third-party system whose model must not leak in | `ddd-anticorruption-layer` |
| One team serves many consumer teams via a stable published API | `ddd-open-host-service`, `ddd-published-language` |
| Integration cost exceeds its value for two divergent models | `ddd-separate-ways` |
| Ad hoc integration, no clear model anywhere | `ddd-big-ball-of-mud` |
| Long-lived business transaction spanning contexts, time-outs | `ddd-long-running-processes` |
| Need a read-optimized view distinct from the write model | `ddd-cqrs` |
| Need to reconstruct Aggregate state from business-meaningful history with real replay/audit value | `ddd-event-sourcing` |
| Small, short-lived, single-team app with little long-term investment | `ddd-smart-ui-anti-pattern` |
| Need to communicate the identified Core cheaply | `ddd-domain-vision-statement`, `ddd-highlighted-core` |
| Complex but non-differentiating computation buried in the Core | `ddd-cohesive-mechanism` |
| Transactional consistency boundary, invariants, concurrency | `ddd-aggregate` |

Load `references/implementation.md` for the full worked example (a veterinary-clinic network
platform), the Pattern-Selection Record template, and tests.

## Verifying

Gather evidence first: locate the written subdomain classification (or its absence), the stated
justification for any "Core" label, the context map or integration description, and whether
tactical-pattern choices (Aggregates, Event Sourcing, CQRS, microservices) are differentiated across
subdomains or applied uniformly. Search for complexity/risk language ("most code," "mission
critical") used as a stand-in for differentiation, and for context-map relationships described only
technically with no named pattern. Run every check in `references/review-checklist.md` and report
using this verdict block:

```
Pattern: ddd-selecting-patterns
Verdict: CONFORMS | PARTIAL | VIOLATES | NOT APPLICABLE
Findings:
- [C<n>] <severity: high|medium|low> <file:line or artifact section> — <evidence> — <fix>
Not checked: <checks skipped and why, or "none">
```

NOT APPLICABLE means no strategic selection decision is actually in question here — either the
system doesn't warrant DDD at all (say so, point to `ddd-smart-ui-anti-pattern`) or the request is
really a single already-scoped pattern question (point to that skill by name).

## Designing with a human

**First-reply contract.** When a human opens a design conversation, your first reply contains exactly three parts, in order: (1) one sentence restating their goal in their own domain terms; (2) the single highest-leverage question below that their situation leaves unanswered; (3) one sentence on how the answer changes the design. It contains no proposed classes, schemas, folder trees, diagrams, code, pattern verdicts, or second question. Later turns take the remaining questions one at a time.

Ask one question per turn; each answer narrows which skill to route to next.

1. "What decision do you actually need help with — where to invest effort, how two teams/systems should relate, or how to implement one specific thing?" — routes immediately to `ddd-subdomains`, `ddd-context-map`, or a named tactical skill, saving turns.
2. "Have you already classified your subdomains as Core, Supporting, or Generic?" — if no, hand off to `ddd-subdomains` before anything else (P1, P3); if yes, ask for the one-line differentiation justification behind the Core call.
3. "Are your Bounded Contexts already drawn, or still implicit in one codebase?" — routes to `ddd-bounded-context` (not drawn) or `ddd-context-map` (drawn, relationships need naming).
4. "For each pair of contexts that must integrate, what's the real relationship between the teams or systems — one cooperating team, a negotiating upstream, a non-negotiable upstream, a hostile legacy system, or many consumers of one provider?" — use the signals table above to name the context-map pattern.
5. "What tactical or architecture question is left once context and relationship are settled?" — hand off to the specific tactical/architecture skill by name.

Show a short running table: subdomain / classification / context / relationship pattern / skill to
load next. Record the agreed list as a Pattern-Selection Record. Exit when every open question in
the conversation has a named skill assigned and an agreed order to apply them.

## Gotchas

- Event Sourcing proposed "for a uniform persistence story" across every context, including thin integration adapters or raw sensor/telemetry ingestion — scope it to Aggregates with real replay/audit value (`ddd-event-sourcing`), not applied by default.
- Shared Kernel proposed with a team you don't continuously coordinate with (an outsourced vendor, a fixed-price/quarterly-cadence contract, a different company) — Shared Kernel needs at least weekly joint integration; use Customer/Supplier or Conformist with a translation layer instead.
- Conformist chosen for an upstream that would actually negotiate — Conformist is for a non-negotiable, uninterested, or vastly more powerful upstream; a willing upstream calls for Customer/Supplier.
- Microservice-per-entity or per-aggregate decomposition mistaken for Bounded Context design — a context is sized to where the model and language genuinely diverge, never to a per-entity or per-table technical slice (P4).
- Treating "most code" or "most complex" as proof of Core Domain — complexity and risk are not differentiation; the test is whether a competitor could copy it and hurt you.
- Full tactical rigor (Aggregates, Repositories, rich invariants) poured into a subdomain already classified Generic "so it doesn't feel second-class" — that directly contradicts the classification (P2, P8).
- Architecture style (Hexagonal, EDA, CQRS, microservices) chosen before context boundaries are settled, then applied uniformly across contexts that actually need different levels of rigor (P6).
- Large-scale structure or distillation technique proposed as a substitute for drawing honest Bounded Context boundaries, rather than layered on top once contexts already exist — Evans ch. 17 treats context, distillation, and structure as complementary, never as replacements for each other.
- Skipping the "is DDD worth it here" question entirely — a simple, short-lived, or single-team system can be over-engineered by forcing it through this hub's full flow when Smart UI would serve it better (P10).

## Related skills

- `ddd-collaborative-design` — the sibling hub for end-to-end, turn-by-turn facilitation once this hub (or the human) has decided DDD applies.
- `ddd-subdomains` — the classification step this hub always performs first.
- `ddd-core-domain` / `ddd-generic-subdomain` — deeper mechanics for whichever classification a subdomain receives.
- `ddd-bounded-context` / `ddd-context-map` — the solution-space steps that follow classification.
- `ddd-shared-kernel` / `ddd-customer-supplier` / `ddd-conformist` / `ddd-partnership` / `ddd-anticorruption-layer` / `ddd-open-host-service` / `ddd-published-language` / `ddd-separate-ways` / `ddd-big-ball-of-mud` — the context-relationship patterns this hub routes to by signal.
- `ddd-event-sourcing` / `ddd-cqrs` — architecture-level tactical patterns frequently misselected uniformly; this hub scopes when they actually apply.
- `ddd-smart-ui-anti-pattern` — the explicit exit ramp when tactical DDD isn't warranted.

## Sources

Evans ch. 17, "Bringing the Strategy Together" (Combining Large-Scale Structures and Bounded
Contexts/Distillation, Assessment First, Who Sets the Strategy?, Six Essentials, Beware the Master
Plan). Evans Appendix, "The Use of Patterns in This Book." Evans Part IV introduction. Evans ch. 14,
"Choosing Your Model Context Strategy" (Transforming Boundaries, Relationships with External
Systems, The Trade-off). Evans ch. 15, "Distillation" (Core Domain, Generic Subdomains determine
tactical investment). Vernon, "Guide to This Book" (strategic-to-tactical big picture). Vernon ch. 1,
"Getting Started with DDD" (Can I DDD?, the DDD Scorecard, Grappling with the Complexity of Your
Domain). Vernon ch. 2, "Domains, Subdomains, and Bounded Contexts." Vernon ch. 3, "Context Maps."