需要定义产品概念模型时用：在接口之前锁定对象、关系、状态…

适用于在写界面、数据库或流程之前，需要把产品认可的对象、关系、状态、动作和术语定清楚，并检验建模决策是否真的开放。

适用场景

解决思路

1. 确定本层要做的决策：产品识别哪些对象，以及每个对象的边界在哪里。
2. 确定这些对象如何关联——包括基数，以及当一个对象扮演多个角色时的具名角色。
3. 确定用户可以对每个对象做什么，或用每个对象做什么。
4. 确定一个对象可以处于哪些状态，以及哪些状态转换重要。
5. 确定产品词汇——一个概念一个名称，一个名称一个概念。
6. 只保留真实对象：用可实例化（可以有很多个）、有结构（有自己的属性）、有用（用户会因其本身而关心）三项检查；防止把属性提升为对象，尤其防止把实例误当成对象；当多个名词属于同一类时，建模该类型为对象，具体名称作为实例或值（例如 CAC、ROAS 是 Metric 的实例，不是对象）。
7. 若某属性只是模型中另一个对象的名称或 ID，把它建模为关系，不要复制该属性。
8. 当一个对象扮演多个角色时，给角色命名，例如写作 belongs to one User (as referrer)，而不是只写 belongs to one User。
9. 不做推测性添加：每个对象、属性、动作和关系都应追溯到已陈述的用户需求；不要把策略词汇当作对象来追溯。
10. 区分「可以是对象」和「应作为一等对象」：用具体流程或任务证明它必须持久化、保存状态并被返回；若没有，则它是临时对象或过早抽象。
11. 当某对象只因未验证的策略赌注而存在时，把它标记为 provisional；把它建模为假设，不要锁死，也不要在该赌注被验证前在其上构建上层。
12. 追求动词精确：检查 Edit、Delete、Update 等通用动词是否掩盖了现实后果不同的操作；例如 Edit address 混淆了纠正拼写错误（覆盖即可）和记录搬家（应保留历史）；当通用动词可能表示真正不同的含义时，分别命名操作，例如 Correct address 与 Register change of address。
13. 把实现与设计分开：当讨论转向如何存储、生成或计算时，拉回到用户能做什么，以及引用了该对象的东西会发生什么；把真正纠缠的问题标记给工程对话，不强行过早回答。
14. 执行 Noun foraging + OOUX（Sophia Prater）：从研究或领域笔记中提取对象，把名词分类为 objects（对象）/ attributes（属性）/ instances-or-values（实例或值）/ set-aside（UI 元素、模糊抽象、伪装成名词的动作），并用 real objects only 测试筛选。
15. 执行 Object definition：钉住一个对象——用一句话从用户视角说明它是什么、它的属性、它的关系（基数和角色名）、它的动作。
16. 执行 Sketch the flow first（push forward, pull back）：当对象性不确定时，先用 `/layers-interaction-flow` breadboard 流程，观察什么必须持久化、保存状态或被返回，然后回来只形式化那些对象；用它区分真实对象和临时对象。
17. 执行 Relational object map（`erDiagram`）：把对象和关系放在一起看，捕捉缺失、反向或虚假的连接；使用 `||`=exactly one、`o{`=zero-or-many、`|{`=one-or-many，many 端用 crow's foot，标签按 first entity → second 读取。
18. 执行 State transition diagram（`stateDiagram-v2`）：对状态变化会改变用户可做事情的对象，命名状态、转换以及每个状态禁止什么。
19. 执行 Action (CTA) inventory：在一处列出用户跨所有对象可采取的所有动作，形成产品的 CTA 词汇；一起列出而不是按对象列出，以暴露不一致（同一操作用 Add vs Create vs New）和过度扁平化（一个动词隐藏不同操作）。
20. 执行 Ubiquitous language list：解决命名争议；对每个有争议概念记录选定术语、被拒绝的替代方案和原因；在 UI、帮助文本、API 名称和内部沟通中保持一个概念一个名称、一个名称一个概念。
21. 执行 Semantic IxD / action grammar（Rosenberg）：审核大量动作和对象之间的动词一致性与精确性。
22. 执行 Event storming — commands/policies（Brandolini）：对流程繁重的领域，从发生什么开始，倒推涉及的对象。
23. 执行 Card sorting：当词汇不清晰或在用户/团队之间有争议时，用它解决。
24. 执行 Walking the existing product：重新设计时，检查当前 UI 所揭示的隐式模型，并与用户实际思考方式比较。
25. 针对会咬人的对象，探查 `/layers-intro` 中的 temporal decisions：中间动作状态、读模型滞后（read-model lag）、关系临时性、删除语义、历史。
26. 与设计师合作：先找出上述哪些决策仍是 live（未决），再提供合适技术——有材料可挖掘时用 noun foraging，重新设计时用 walking the product，或对象已知而只有形状待定时直接进入 object definition；做下一个有用的事，而不是运行整个工具包。
27. 只捕获残留物：已确定的 object definitions（以及哪些仍为 provisional，等待一个赌注或流程验证）、任何编码真实关系或生命周期的图、词汇决策、开放问题（感觉单薄的对象、推迟给工程的决策）；不要写设计师不会重读的报告。
28. 如果领域工作尚未完成，明确说明：在有证据之前，此模型只是假设。
29. 当对象和动作稳定后，下一步是设计用户如何在这些对象和动作之间移动——`/layers-interaction-flow`。

适用边界 · 注意事项

• 当对象、关系、状态、动作和词汇都不是真正开放的决策时，不要为了做而做这一层；直接说明不需要。
• 当领域研究尚未完成时，不要把此概念模型当作已证实设计，它只是假设。
• 不要把它当作数据库 schema、线框图或流程图；也不要与用户混乱的心智模型（领域层）混淆。