layers-domain

/layers-domain

假定已加载 /layers-intro。此技能是一套技巧，而非脚本——请参阅其中的“如何使用这些技能”。

领域层映射现实世界中独立于任何产品而存在的事物：用户已有的概念、术语、流程、关系和心智模型。这是观察，而非设计。

---

此层需要做出的决策

• 该领域的关键概念是什么，以及它们之间有何关系
• 人们使用什么语言——以及语言冲突或分歧之处
• 自然的分界在哪里：哪些群体使用相同的词语，却有不同的含义
• 哪些事件和流程构成了该领域随时间发展的活动

如果该领域已广为人知且没有争议，你可能不需要这一层——直接进入概念模型即可。

---

准则——确保领域工作严谨

• 不要消解矛盾——要记录矛盾。 杂乱、不一致的领域语言是数据：它表明不同群体在哪里出现了分歧，也表明产品之后需要在哪里做出选择。消解矛盾属于概念模型的工作，而非此处的工作。将同义词（同一事物，不同名称）和多义词（相同名称，在不同语境下指不同事物）作为发现记录下来，而非视为问题。
• 立足现实世界。 每当回答偏向产品或界面决策时，都要及时纠正。问题始终是：在你的产品介入之前，领域是如何运作的。
• 区分真实对象与实例（用于名词梳理）。真正的对象应当可实例化（可以有多个）、有结构（有自身属性），且有用（人们本身就关注它）。留意被误认为对象的实例：“CAC”“ROAS”“LTV”不是对象，而是同一对象 Metric 的实例。将每个名词标记为对象 / 属性 / 实例或值 / 不明确——不要过度筛选；筛选工作由概念模型负责。
• 区分信念与现实。 如果你梳理的是团队的认知，而非经研究确认的事实，请始终明确说明——这是团队的模型，不一定符合用户体验该领域的方式。

---

技巧

选择合适的技巧——概念图加术语审查通常是核心组合。

技巧	适用情况
概念图 / 气泡图（graph TD/LR）	领域复杂且缺乏了解。用非正式的节点和连线展示概念之间的关系，避免过早强加结构。
术语审查	针对每个概念记录：所用名称、谁在何时使用哪些名称，以及冲突属于同义还是多义。不要选定某个名称作为唯一标准。
有界上下文映射	各群体内部共享词汇，但不同群体之间存在分歧。为每个分界命名并加以描述——定义模型时会用到这些信息。
名词梳理	汇总出现过的所有名词，并标记为对象 / 属性 / 实例或值 / 不明确。为概念模型提供原始材料。
领域事件风暴（Brandolini）	以流程为主的领域。在时间线上用过去时标记重要事件，并注明触发因素和结果。围绕对象发生的事件通常意味着之后需要状态图。
专家访谈	领域知识存在于人们的头脑中，而非文档中——可借此挖掘隐性知识和有争议的术语。
文档与实物分析	该领域会产生合同、表格、发票等资料，从中可以看出自然结构和词汇。
竞品分析	进入成熟领域时使用——现有产品能展示他人如何建模，以及他们之间的分歧。
跟岗观察	工作流很难用语言描述；观察能揭示人们实际做了什么。

---

与设计师协作

先询问他们要梳理哪个领域、有哪些人在其中运作，以及在任何产品出现之前，他们想要实现什么。然后梳理概念——留意名词（候选对象）、动词（流程）和自然使用的词汇，包括人们实际如何称呼事物。

根据当前问题，采用合适的技巧：关系不清晰时绘制概念图，术语存在争议时审查术语，领域以流程为主时开展事件风暴。先做下一件有用的事，而不是把所有事都做一遍。

只记录梳理所得——若概念图确有价值，就保留它；记录已明确的术语冲突和限界上下文、关键事件以及收集到的名词。这些是原始素材，不是完成的文档。

梳理完领域后，收集到的名词就是 /layers-conceptual-model 的起点。