Back to Details

layers-domain

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/layers-domain

/layers-domain

Assumes 
/layers-intro
has been loaded for framework context.
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.
Critical distinction: Do not resolve contradictions at this layer. Contradictory, messy, inconsistent domain language is data — it signals where different user communities have diverged, and where the product will need to make deliberate choices. Resolution happens at the conceptual model layer.
Decisions this layer needs to make:
  • What are the key concepts in this domain, and how do they relate?
  • What language do people use — and where does that language conflict or diverge?
  • Where are the natural seams where different communities use the same words differently?
  • What events and processes structure the domain's activity over time?
Methods:
MethodWhen
Concept maps / bubble diagramsDomain is complex and poorly understood. Informal nodes-and-lines show how concepts relate without forcing premature structure.
Domain event storming (Brandolini)Domain is process-heavy. Start from significant things that happen (past tense) — events reveal natural seams.
Expert interviewsDomain knowledge lives in people, not documents. Conversations reveal tacit knowledge and contested terminology.
Document and artefact analysisDomain produces artefacts (contracts, forms, invoices) that reveal natural structure and vocabulary.
Competitive analysisEntering an established domain. Existing products reveal how others have modelled it — and where they disagree.
ShadowingDomain involves workflows hard to articulate. Watching people work reveals what they actually do.
Default: concept mapping and terminology audit.
Quality signals — what good looks like:
  • Contradictions are documented, not resolved
  • Synonyms are recorded (same thing, different names)
  • Polysemy is flagged (same name, different things in different contexts)
  • Bounded contexts are named where communities use language coherently within their group but inconsistently across groups
  • The noun harvest is a complete raw candidate list — not filtered, not pre-organised into objects and attributes
假设已加载
/layers-intro
以了解框架背景。
领域层映射独立于任何产品的现实世界存在：包括用户自带的概念、术语、流程、关系和心智模型。这是观察，而非设计。
关键区别： 不要在这一层解决矛盾。矛盾、混乱、不一致的领域语言是数据——它标志着不同用户群体的分歧之处，以及产品需要做出审慎选择的地方。矛盾的解决发生在概念模型层。
该层需要做出的决策：
  • 该领域的关键概念是什么，它们之间有何关联？
  • 人们使用哪些语言——这些语言在哪些地方存在冲突或分歧？
  • 哪些自然边界下，不同群体对同一词汇的使用方式不同？
  • 哪些事件和流程随时间构建了领域的活动？
方法：
方法使用场景
概念图/气泡图领域复杂且了解不足。非正式的节点连线展示概念间的关联，无需强制过早构建结构。
Domain event storming（Brandolini提出）领域以流程为主。从发生过的重要事件（过去式）入手——事件会揭示自然边界。
专家访谈领域知识存在于人而非文档中。对话能揭示隐性知识和有争议的术语。
文档与人工制品分析领域会产生人工制品（合同、表单、发票），这些制品能揭示自然结构和词汇。
竞品分析进入已成熟的领域。现有产品展示了他人如何对该领域建模，以及他们的分歧之处。
影子调研领域涉及难以表述的工作流程。观察人们的工作能揭示他们实际的操作方式。
默认方法：概念映射与术语审计。
质量信号——优秀的领域层是什么样的：
  • 矛盾被记录，而非解决
  • 同义词被记录（同一事物，不同名称）
  • 一词多义被标记（同一名称，在不同语境下指代不同事物）
  • 命名限界上下文：在这些语境中，群体内部词汇使用一致，但跨群体存在不一致
  • 名词集合是完整的原始候选列表——未经过滤，未预先组织为对象和属性

Guided session

引导式会话

Tell me what domain you're mapping and what you know about it, or say "guide me" to start a structured session.
Ask: "Where should I capture the work from this session?" (see 
/layers-intro
for options)
Ask: "Are you working from research and domain expertise, or from what the team currently believes about the domain?" If mapping beliefs, flag throughout that what's being captured is the team's model, not necessarily how users experience the domain.
Phase 1 — Frame the domain
  1. What domain are we mapping? (The real-world context — not the product.)
  2. Who are the people operating in this domain? (Roles, user types, stakeholders.)
  3. What are they trying to accomplish, before your product enters the picture?
Keep pushing back toward the real world if answers drift toward product decisions.
Phase 2 — Surface the concepts
"Walk me through how [domain] works. What are the main things, how do they relate, what happens?"
Listen for nouns (concepts), verbs (processes), and natural vocabulary. Take notes on everything — raw, unfiltered. Then prompt:
  • "What do people actually call these things? Multiple names for the same thing?"
  • "What rules exist — explicit policies or understood conventions?"
  • "What changes over time? What has a lifecycle?"
Phase 3 — Concept map
Build a concept map: nodes connected by labelled relationships. Informal — no required hierarchy or orientation; follow what feels natural for the domain. In Mermaid: 
graph TD
or 
graph LR
.
Ask: "Does this feel like the domain, or like a database diagram? What's missing or wrong?"
Phase 4 — Terminology audit
For each concept: does everyone in this domain use this word the same way? Are there other words for the same thing? Does this word mean something different in another context?
Document:
Concept: [thing]
Names used: [all variants]
Context: [who uses which, and when]
Conflict type: synonyms (same thing, different names) / polysemy (same name, different things)
Do not choose a winner.
Phase 5 — Bounded contexts
Look at terminology conflicts: are there communities of people who share vocabulary internally but diverge from other groups? Name and describe each. These seams will matter when the conceptual model is defined — the product will need to decide how to navigate or bridge them.
Phase 6 — Domain events (optional)
If the domain is process-heavy: "What are the significant things that happen in this domain? Name them in past tense."
List events on a timeline. Ask what triggers each, and what happens as a result. Objects with significant events around them are likely to need state transition diagrams at the conceptual model layer.
Phase 7 — Noun harvest
Compile all nouns surfaced in the session. Mark each:
  • Potential object — independently meaningful, may have attributes and relationships
  • Potential attribute — a property of something else
  • Unclear — needs more thought
Don't filter aggressively. The conceptual model layer does the sorting.
告诉我你正在映射的领域以及你对它的了解，或者说“引导我”来开始结构化会话。
提问：“我应该在哪里记录本次会话的成果？”（查看
/layers-intro
了解选项）
提问：“你是基于研究和领域专业知识进行映射，还是基于团队当前对领域的认知？” 如果是映射认知，全程需标注所记录的是团队的模型，而非用户实际体验的领域。
阶段1 — 界定领域范围
  1. 我们正在映射哪个领域？（现实世界背景——而非产品。）
  2. 该领域中的参与者是谁？（角色、用户类型、利益相关者。）
  3. 在你的产品介入之前，他们想要达成什么目标？
如果答案偏向产品决策，要引导回到现实世界层面。
阶段2 — 挖掘概念
“带我了解[领域]的运作方式。主要涉及哪些事物，它们之间有何关联，会发生什么？”
留意名词（概念）、动词（流程）和自然词汇。记录所有内容——原始、未过滤。然后提示：
  • “人们实际如何称呼这些事物？同一事物有多个名称吗？”
  • “存在哪些规则——明确的政策或默认的惯例？”
  • “哪些事物会随时间变化？哪些有生命周期？”
阶段3 — 绘制概念图
构建概念图：节点通过带标签的关系连接。无需严格的层级或方向，遵循领域的自然逻辑即可。使用Mermaid语法：
graph TD
或 
graph LR
。
提问：“这感觉符合领域实际情况，还是更像数据库图？缺少或错误的内容是什么？”
阶段4 — 术语审计
针对每个概念：该领域中的所有人对这个词汇的使用方式是否一致？同一事物是否有其他词汇？这个词汇在另一个语境中是否有不同含义？
记录格式：
概念: [事物]
使用的名称: [所有变体]
语境: [谁在何时使用哪个名称]
冲突类型: 同义词（同一事物，不同名称）/ 一词多义（同一名称，不同事物）
不要选定“标准”名称。
阶段5 — 识别限界上下文
查看术语冲突：是否存在一些群体，其内部词汇使用一致，但与其他群体存在分歧？为每个这样的群体命名并描述。这些边界在定义概念模型时至关重要——产品需要决定如何导航或跨越这些边界。
阶段6 — 领域事件（可选）
如果领域以流程为主：“该领域中发生的重要事件有哪些？用过去式命名。”
将事件按时间线列出。询问每个事件的触发因素和结果。围绕其存在重要事件的对象，可能需要在概念模型层绘制状态转换图。
阶段7 — 生成名词集合
汇总会话中出现的所有名词。为每个名词标记：
  • 潜在对象 — 具有独立意义，可能包含属性和关系
  • 潜在属性 — 其他事物的属性
  • 不明确 — 需要进一步思考
不要过度筛选。概念模型层会进行分类整理。

Completion

完成标志

Produce:
  1. Concept map — Mermaid 
    graph TD
  2. Terminology conflicts — documented name variants and bounded contexts
  3. Domain events — if explored, key events timeline
  4. Noun harvest — complete candidate list
Close with: "This domain map is raw material for your conceptual model. Run 
/layers-conceptual-model
to define objects, relationships, and vocabulary — the noun harvest is your starting point."
产出：
  1. 概念图 — Mermaid 
    graph TD
    格式
  2. 术语冲突记录 — 已记录的名称变体和限界上下文
  3. 领域事件 — 若已探索，提供关键事件时间线
  4. 名词集合 — 完整的候选列表
收尾提示：“此领域图是概念模型的原始素材。运行
/layers-conceptual-model
来定义对象、关系和词汇——名词集合将是你的起点。”