---
name: ddd-collaborative-design
description: >-
  Collaborative Design from Domain-Driven Design: the facilitation hub for running a DDD engagement
  end to end, assessment through Core Domain and Bounded Contexts to tactical handoff. Use when
  kicking off a DDD effort, facilitating domain experts, planning discovery, or reviewing a
  facilitation transcript for master-plan or questionnaire mistakes.
metadata:
  ddd.category: hub
  ddd.sources: "Evans ch. 1, ch. 2, ch. 17; Vernon ch. 1-3"
---

# Collaborative Design

This hub does not teach a tactical or structural pattern; it teaches the order and discipline for
facilitating a DDD engagement with a human — from the first conversation through to handing off to
the specific pattern skills that do the detailed work. The core principle is Assessment First
(Evans ch. 17): understand the current situation (Context Map, language, Core Domain, team/tech
fit) before producing any committed artifact, and keep every structural decision revisable as
understanding deepens. It buys a team an engagement that reaches correct boundaries and a correct
Core Domain instead of a premature, over-specified plan nobody can actually use.

## How to use this skill

| Mode | What to do | Which file to read and when |
|---|---|---|
| Implement | Produce the session's artifacts — a phased facilitation plan, a decision log, a provisional Context Map, a candidate subdomain/Core Domain note — following the phase order and P-rules | Load `references/implementation.md` for the worked recipe, filled templates, and the decision-log/phase-state model |
| Verify | Review a facilitation transcript or a selection/design document against every check in `references/review-checklist.md`; report in the verdict format | Always load the checklist before judging a transcript or plan |
| Select | Decide which pattern skill(s) this engagement needs next, in what order, by the phase the engagement is currently in | Read this file's "When to use" and "Implementing" sections first; defer to `ddd-selecting-patterns` once a specific tactical/structural choice (not facilitation order) is the open question |
| Design with a human | Run the phases below, one question per turn, until each phase's exit criterion is met | Load `references/design-facilitation.md` for the ordered question library, decision-log template, and handoff table |

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

## Core rules

- **P1 — Assessment before any committed artifact.** Before producing a roadmap, a locked Context Map, or any tactical artifact, work through Evans's assessment checklist: can you draw a consistent Context Map (even a rough one)? Is there a Ubiquitous Language, and is it rich enough? Is the Core Domain identified? Does the technology help or hinder Model-Driven Design? Do the developers have the skills, and the domain interest, needed? Treat the answers as provisional and revisit them.
- **P2 — Strategic before tactical.** Sequence Context Map, Core Domain, and Bounded Context work ahead of Aggregate/Repository/Entity-level tactical modeling. Tactical modeling starts only once a Bounded Context and its Core-vs-supporting status are at least provisionally known, and only where the Core Domain (or a part the team has deliberately chosen to invest in) actually lives.
- **P3 — One question per turn; ask the highest-leverage question next.** Never present a multi-item questionnaire. At each turn, ask the single question whose answer would most change the plan — the one most likely to invalidate an assumption, reveal a missing Bounded Context, or redirect where investment should go — not the next item on a fixed checklist.
- **P4 — Adopt the domain expert's term immediately and propagate the correction.** When a domain expert supplies or corrects a term, every subsequent artifact (diagrams, glossary, code names mentioned aloud) must use that term from that point forward. A single "got it" that is not followed through in the next artifact is a Ubiquitous Language failure, not a minor slip.
- **P5 — Identify the domain expert for each area before relying on their answers for it.** Availability is not expertise. If the person in the room has told you (or it is otherwise evident) that another part of the domain is owned by a different team or person, do not extend their answers to cover that area; name the gap and plan to bring in the right person.
- **P6 — No master plan locked in before feedback; the structure must allow evolution.** A large-scale structure, full Context Map, or multi-context roadmap presented as settled before the team has had a chance to react to it is a Master Plan and will fail the way master plans fail: too rigid to adapt, and alienating to the people who must live with it. Whatever structure is proposed, label it provisional until it has been through at least one round of team feedback.
- **P7 — Core Domain drives investment and sequencing, not codebase size, age, or bug count.** A system being the biggest, oldest, or buggiest is a maintenance-priority signal, not a strategic-importance one. Find what differentiates the business (what customers or sales cite, what the team would protect from competitors) before deciding where facilitation and tactical effort go first.
- **P8 — Record every decision, with rationale, in a decision log.** Model decisions, boundary calls, and vocabulary corrections are written down with what was decided, why, who decided it, and what it supersedes — not left to live only in a transcript or someone's memory.
- **P9 — Hand off by name once a phase's exit criterion is met.** This hub stops short of doing a pattern skill's detailed work. Once a phase produces what the next skill needs (e.g., a provisional subdomain list for `ddd-subdomains`, a drafted relationship for `ddd-context-map`), name that skill and move the detailed work there.
- **P10 — Decisions reached here are hypotheses, not verdicts for the whole team.** Per the Six Essentials (Evans ch. 17): the decision must still reach and be absorbable by the whole team, must not siphon the best engineers away from application work, and must be pared down to the minimum that actually helps — resist the urge to over-elaborate a structure just because the facilitation session generated momentum.

## When to use

**Signals it fits**
- A DDD engagement is starting (new project, new team, new domain) and no Context Map, Ubiquitous Language, or Core Domain has been established yet.
- A human stakeholder is in the room (or in a transcript) and the open question is "what do we do first, and in what order," not "how do I implement pattern X."
- Multiple candidate domains/subdomains/systems exist and the engagement must decide where to start given limited engagement capacity.
- A facilitation transcript or discovery plan needs review for whether it followed assessment-first, strategic-before-tactical, Ubiquitous Language, and anti-master-plan discipline.

**Signals it does not fit / over-engineering**
- The team already has an agreed Core Domain, Bounded Contexts, and Context Map, and the open question is a specific tactical or structural pattern choice (e.g., "should this be one Aggregate or two") — go straight to that pattern's skill or to `ddd-selecting-patterns`.
- There is no human to facilitate with at all (pure code review of an existing system) — use the specific pattern's `Verify` mode instead.
- Running this hub's phases as a bureaucratic gate that delays all code indefinitely is itself a misapplication; assessment should be fast and provisional (days, not months) and should produce artifacts the team can act on, not stall on.

**Alternatives** (prerequisite: none — this is usually the first skill loaded in a new engagement)
- `ddd-selecting-patterns` — once the open question is "which pattern(s) fit this specific, already-scoped codebase or scenario," rather than "how do we run this facilitation end to end."
- `ddd-knowledge-crunching` — deep technique for one scenario-walkthrough/knowledge-crunching session, once that is the active phase.
- `ddd-ubiquitous-language` — deep technique for building and maintaining the glossary once language work is the active focus.
- `ddd-core-domain` / `ddd-subdomains` — deep rules once Core Domain identification or subdomain classification is the active focus.
- `ddd-context-map` / `ddd-bounded-context` — deep technique once context-map drafting or bounded-context sizing is the active focus.

## Implementing

1. Open with assessment, not a deliverable request: walk the Evans ch. 17 checklist (Context Map? Language? Core Domain? Tech fit? Team skill and interest?) as the first artifact, explicitly labeled provisional. (P1)
2. If leadership or an architect pushes for a locked roadmap or a pre-made large-scale diagram immediately, reframe the deliverable: a discovery plan plus a labeled hypothesis, not a finished architecture. (P6)
3. Run scenario walkthroughs with the actual domain expert(s) for each area in scope, one concrete end-to-end scenario at a time, capturing their own words as they're said. (P3, P4)
4. Build the glossary/Ubiquitous Language artifact incrementally from those walkthroughs; when a term is corrected, update every downstream artifact before producing the next one. (P4)
5. For each area touched, confirm who the authoritative domain expert is; flag and defer areas no one present actually owns rather than extrapolating. (P5)
6. Sketch a provisional Context Map across all systems/teams in scope, even areas not yet actively modeled, so relationships are visible early. (P1, P2)
7. Identify the Core Domain by differentiation (what the business would protect, what customers cite), not by codebase size, age, or criticality; let this call drive where tactical effort starts. (P7)
8. Record each boundary/vocabulary/priority decision in the decision log as it is made, not retroactively. (P8)
9. At each phase's exit criterion, name the specific pattern skill(s) the next detailed work belongs to and stop doing that work here. (P9)
10. Present progress, not a locked structure, to any wider audience; mark what is confirmed versus still hypothesis, and name the next round's open questions. (P6, P10)

Load `references/implementation.md` for the filled worked example (a fresh domain, phase-by-phase artifacts) and the decision-log/phase-state Python model with tests.

## Verifying

Gather evidence first: locate the facilitation transcript or discovery/design-with-human document, any decision log, glossary, Context Map sketch, and subdomain/Core Domain notes produced during the engagement. Note the order artifacts were produced in and whether questions came one at a time or as a batch. Run every check in `references/review-checklist.md` and report using this verdict block:

```
Pattern: ddd-collaborative-design
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 this isn't a facilitation-with-a-human artifact at all (e.g., it's a finished codebase with no engagement history) — say so, and point to the specific pattern skill's own `Verify` mode instead.

## 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.

Run six phases in order: assess current state and Context Map → identify the Core Domain → bound Contexts → map relationships between them → build the core model through scenarios → hand off to tactical pattern skills. At every turn ask exactly one question — the highest-leverage one, the one most likely to overturn an assumption or redirect investment — never a batch. Adopt and keep using the domain expert's own words; when corrected, fix every artifact produced since. Confirm who the authoritative expert is for each area before leaning on their answers for it. Record every decision in a running decision log with rationale. Each phase has its own exit criterion (e.g., "a provisional Context Map exists and has been shown to the team" before leaving the assess phase); do not advance past a phase, and do not let any artifact be presented as final, until its criterion is met.

Load `references/design-facilitation.md` for the full ordered question library per phase, the decision-log template, the phase exit criteria, and the phase-to-skill handoff table.

## Gotchas

- Treating "assessment first" as permission to stall: the assessment checklist (P1) is meant to take days, produce a provisional artifact, and move the engagement forward — not to become an open-ended discovery phase that never produces anything actionable.
- Sending a domain expert a written requirements questionnaire ("list all entities, attributes, relationships...") instead of walking concrete scenarios together is the single most common facilitation failure; it produces a data-schema-shaped answer, not domain insight, and it isn't collaborative (Evans ch. 1, "knowledge crunching is not a solitary activity"; Vernon ch. 1, "listen and listen carefully").
- Correcting a term once ("got it") and then continuing to use the old term in the very next diagram or code sketch is worse than not asking at all — it signals the correction wasn't really heard.
- Presenting a full large-scale structure or multi-context roadmap as a deliverable in the same session as the first scenario or the first vocabulary fix is a Master Plan, regardless of how good the diagram looks; it hasn't been through a feedback round yet.
- "Biggest codebase" or "most bug reports" is a maintenance-urgency signal, not a Core Domain signal; don't let codebase size substitute for the differentiation question in P7.
- One available person is not automatically the domain expert for every area in scope — check ownership explicitly (P5) before building a shared model across areas that different teams actually run.
- Evans ch. 17 frames strategy-setting organizationally (emergent structure from the application team vs. a customer-focused architecture team, plus the Six Essentials); Vernon ch. 1 frames the same discipline more operationally (the DDD scorecard, "how to do DDD" via Ubiquitous Language and Bounded Context) — both point to the same ordering (assess, then strategic, then tactical), but Evans is the source for the organizational "who decides" guidance and the master-plan critique, while Vernon is the source for the concrete first-session "how."
- A generic subdomain signal volunteered by a domain expert (e.g., "that data is fixed by an external authority, we don't control it") is easy to miss if the facilitator is focused on the next scripted question; the one-question-at-a-time discipline (P3) exists partly so the facilitator is actually listening for signals like this, not just working down a list.

## Related skills

- `ddd-selecting-patterns` — the sibling hub for choosing among specific patterns once a scenario is already scoped; this hub governs the facilitation order that gets you to that point.
- `ddd-knowledge-crunching` — the technique behind scenario walkthroughs and brainstorming with domain experts.
- `ddd-ubiquitous-language` — the deep rules for building, correcting, and maintaining the glossary.
- `ddd-model-driven-design` / `ddd-hands-on-modelers` — once the team is actively modeling, not just assessing.
- `ddd-subdomains` — classifying candidate subdomains as core/supporting/generic.
- `ddd-core-domain` — the rules for what happens once a Core Domain is identified (staffing, confidentiality, refactor priority).
- `ddd-context-map` / `ddd-bounded-context` — drafting and sizing the Context Map and its Bounded Contexts.
- `ddd-domain-vision-statement` — the lightweight artifact for communicating the Core Domain once identified.
- `ddd-evolving-order` — governs how much structure to commit to and how it should change over time, once a large-scale structure is in play.
- `ddd-anticorruption-layer` / `ddd-generic-subdomain` — typical next steps once an external or non-differentiating system is surfaced during assessment.

## Sources

Evans ch. 1, "Crunching Knowledge" (Ingredients of Effective Modeling, Knowledge Crunching, Continuous Learning). Evans ch. 2, "Communication and the Use of Language" (Ubiquitous Language, Modeling Out Loud, One Team One Language). Evans ch. 17, "Bringing the Strategy Together" (Assessment First, Who Sets the Strategy?, Six Essentials for Strategic Design Decision Making, Beware the Master Plan). Vernon ch. 1, "Getting Started with DDD" (Can I DDD?, How to Do DDD, Ubiquitous Language). Vernon ch. 2, "Domains, Subdomains, and Bounded Contexts." Vernon ch. 3, "Context Maps." Vernon, "Guide to This Book" (strategic modeling before tactical).