layers-domain
jamiemill/layers-skills
Map domain concepts, terminology conflicts, and bounded contexts before building the conceptual model.
What is layers-domain?
Techniques for understanding the real-world domain independently of product design: what concepts exist, how people talk about them, where language conflicts, and what natural communities or seams divide the space. Use this when entering a complex or contested domain to surface the raw material the conceptual model will later structure.
- Document key concepts and how they relate using concept maps or bubble diagrams
- Capture terminology conflicts: synonyms (same thing, different names) and polysemy (same name, different meanings across contexts)
- Identify bounded contexts where communities use shared vocabulary internally but diverge across groups
- Harvest nouns and mark each as object, attribute, instance-or-value, or unclear
- Map domain events and processes in past tense to reveal state and triggers
- Surface tacit knowledge and contested terms through expert interviews and shadowing
How to install layers-domain
npx skills add https://github.com/jamiemill/layers-skills --skill layers-domain- Assumes /layers-intro has been loaded
- Access to domain experts, users, or documentation
- Time for interviews, shadowing, or document analysis
How to use layers-domain
- 1.Identify the domain, its key stakeholders, and what they accomplish before any product exists
- 2.Choose techniques that fit your live question: concept maps for unclear relations, terminology audits for contested language, event storming for process-heavy domains, shadowing for tacit workflows
- 3.Conduct interviews, analyze documents and artifacts, or observe users to surface concepts, nouns, verbs, and natural vocabulary
- 4.Document findings: concept map (if it earned its place), terminology conflicts with synonyms and polysemy marked, bounded contexts named, key events, and a noun harvest marked by type
- 5.Pass the noun harvest to /layers-conceptual-model as the starting point for the next layer
Use cases
- Entering an established market: analyze how competitors modeled the domain to understand where they disagree
- Process-heavy domain: use event storming to name significant events and their triggers and results
- Poorly understood domain: create informal concept maps to show relationships without forcing premature structure
- Contested terminology: audit who calls what by which name and in which contexts, documenting conflicts rather than resolving them
- Workflow discovery: shadow users to reveal what they actually do versus what they say they do
- Product strategists mapping unfamiliar domains
- Domain-driven design practitioners building conceptual models
- Teams entering competitive or regulated markets
- Designers and engineers working with domain experts
- Anyone modeling complex, multi-stakeholder problem spaces
layers-domain FAQ
No. Record conflicts as data — they signal where communities have diverged and where the product will later have to choose. Resolution belongs to the conceptual model, not the domain layer.
A true object is instanceable (you can have many), structured (has its own attributes), and useful (people care about it in its own right). Instances like 'CAC' or 'LTV' are values of a larger object like Metric, not objects themselves.
No. Concept mapping plus a terminology audit is the usual core. Pick what fits the live question and do the next useful thing, not all of them.
You may not need this layer at all — go straight to /layers-conceptual-model.
When you have a noun harvest, documented terminology conflicts and bounded contexts, a concept map (if it earned its place), and any key events. This is raw material for the conceptual model, not a finished document.
Full instructions (SKILL.md)
Source of truth, from jamiemill/layers-skills.
name: layers-domain description: Techniques for mapping a domain's concepts, terminology conflicts, and bounded contexts — the raw material the conceptual model is built from
/layers-domain
Assumes /layers-intro has been loaded. This skill is a library of techniques, not a script — see "How to use these skills" there.
The domain layer maps what exists in the real world independently of any product: the concepts, terminology, processes, relationships, and mental models users bring with them. This is observation, not design.
The decisions this layer makes
- What the key concepts in this domain are, and how they relate
- What language people use — and where it conflicts or diverges
- Where the natural seams are: communities that use the same words differently
- What events and processes structure the domain's activity over time
If the domain is already well understood and uncontested, you may not need this layer — go straight to the conceptual model.
Disciplines — what keeps domain work honest
- Don't resolve contradictions — record them. Messy, inconsistent domain language is data: it signals where communities have diverged and where the product will later have to choose. Resolution belongs to the conceptual model, not here. Capture synonyms (same thing, different names) and polysemy (same name, different things in different contexts) as findings, not problems.
- Stay in the real world. Push back whenever answers drift toward product or interface decisions. The question is always how the domain works before your product enters it.
- Real objects vs instances (for the noun harvest). A true object is instanceable (you can have many), structured (has its own attributes), and useful (people care about it in its own right). Watch for instances mistaken for objects: "CAC", "ROAS", "LTV" aren't objects, they're instances of one object, Metric. Mark each noun object / attribute / instance-or-value / unclear — and don't filter aggressively; the conceptual model does the sorting.
- Beliefs vs reality. If you're mapping what the team believes rather than researched fact, say so throughout — it's the team's model, not necessarily how users experience the domain.
Techniques
Pick what fits — concept mapping plus a terminology audit is the usual core.
| Technique | Use it when |
|---|---|
Concept maps / bubble diagrams (graph TD/LR) | The domain is complex and poorly understood. Informal nodes-and-lines show how concepts relate without forcing premature structure. |
| Terminology audit | Capture, per concept: the names used, who uses which and when, and whether the conflict is synonymy or polysemy. Don't pick a winner. |
| Bounded-context mapping | Communities share vocabulary internally but diverge across groups. Name and describe each seam — it will matter when the model is defined. |
| Noun harvest | Compile every noun surfaced, marked object / attribute / instance-or-value / unclear. Raw material for the conceptual model. |
| Domain event storming (Brandolini) | Process-heavy domain. Name significant events in past tense on a timeline; note triggers and results. Objects with events around them likely need state diagrams later. |
| Expert interviews | Domain knowledge lives in people, not documents — surfaces tacit knowledge and contested terms. |
| Document & artefact analysis | The domain produces contracts, forms, invoices that reveal natural structure and vocabulary. |
| Competitive analysis | Entering an established domain — existing products reveal how others modelled it, and where they disagree. |
| Shadowing | Workflows are hard to articulate; watching reveals what people actually do. |
Working with the designer
Open by asking what domain you're mapping, who operates in it, and what they're trying to accomplish before any product exists. Then surface concepts — listen for nouns (candidate objects), verbs (processes), and the natural vocabulary, including what people actually call things.
Offer the technique that fits the live question: a concept map when relations are unclear, a terminology audit when language is contested, event storming when the domain is process-heavy. Do the next useful thing, not all of them.
Capture only the residue — the concept map if it earned its place, the documented terminology conflicts and bounded contexts, any key events, and the noun harvest. This is raw material, not a finished document.
When the domain is mapped, the noun harvest is the starting point for /layers-conceptual-model.
Related skills
More from jamiemill/layers-skills and the wider catalog.
layers-interaction-flow
Map interaction structure and flow—places, affordances, edge cases—without committing to visual form.
layers-intro
Framework orientation for Layers of Product Design — foundational context for all related design skills.
layers-observed-behaviour
Plan and synthesize user research into grounded, confidence-rated findings about actual user behavior.
layers-orient
Rapid diagnostic to identify which design layer needs attention most urgently.
layers-product-strategy
Connect user needs to business outcomes and test strategic bets with minimal cost.
layers-surface
Audit and refine UI/UX surface against underlying conceptual models, interaction flows, and accessibility standards.