Back to Details

domain-modeling

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Domain Modeling

领域建模

Actively build and sharpen the project's domain model as you design. This is the active discipline — challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely reading 
CONTEXT.md
for vocabulary is not this skill — that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
在设计过程中主动构建并优化项目的领域模型。这是一项主动的工作——质疑术语、设想边缘场景，并在术语和决策明确的那一刻就将其记录到术语表中。（仅仅为了获取词汇而阅读
CONTEXT.md
不属于这项技能——那是任何技能都能做到的简单习惯。这项技能适用于修改模型的场景，而非仅仅使用模型。）

File structure

文件结构

Most repos have a single context:
/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/
If a 
CONTEXT-MAP.md
exists at the root, the repo has multiple contexts. The map points to where each one lives:
/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← system-wide decisions
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← context-specific decisions
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/
Create files lazily — only when you have something to write. If no 
CONTEXT.md
exists, create one when the first term is resolved. If no 
docs/adr/
exists, create it when the first ADR is needed.
大多数仓库只有一个上下文：
/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/
如果根目录下存在
CONTEXT-MAP.md
，则该仓库包含多个上下文。该文件会指明每个上下文的位置：
/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← 系统级决策
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← 上下文专属决策
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/
按需创建文件——只有当有内容需要记录时才创建。如果不存在
CONTEXT.md
，则在第一个术语确定时创建它。如果不存在
docs/adr/
目录，则在需要创建首个ADR时创建该目录。

During the session

会话过程中

Challenge against the glossary

对照术语表提出质疑

When the user uses a term that conflicts with the existing language in 
CONTEXT.md
, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
当用户使用的术语与
CONTEXT.md
中的现有语言冲突时，立即指出。例如：“你的术语表将‘取消’定义为X，但你似乎指的是Y——到底是哪一个？”

Sharpen fuzzy language

优化模糊语言

When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
当用户使用模糊或多义术语时，提出精准的标准术语。例如：“你提到‘账户’——你指的是Customer还是User？这两者是不同的概念。”

Discuss concrete scenarios

讨论具体场景

When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
当讨论领域关系时，用具体场景进行压力测试。设想能够探测边缘情况的场景，迫使用户明确概念之间的边界。

Cross-reference with code

与代码交叉验证

When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
当用户说明某事物的工作方式时，检查代码是否与之相符。如果发现矛盾，及时指出：“你的代码会取消整个Order，但你刚才说支持部分取消——哪个是正确的？”

Update CONTEXT.md inline

实时更新CONTEXT.md

When a term is resolved, update 
CONTEXT.md
right there. Don't batch these up — capture them as they happen. Use the format in CONTEXT-FORMAT.md.
CONTEXT.md
should be totally devoid of implementation details. Do not treat 
CONTEXT.md
as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
当术语确定后，立即更新
CONTEXT.md
。不要批量处理——在确定的那一刻就记录下来。使用CONTEXT-FORMAT.md中的格式。
CONTEXT.md
应完全不含实现细节。不要将
CONTEXT.md
当作规范、草稿本或实现决策的存储库。它只是一个术语表，仅此而已。

Offer ADRs sparingly

谨慎创建ADR

Only offer to create an ADR when all three are true:
  1. Hard to reverse — the cost of changing your mind later is meaningful
  2. Surprising without context — a future reader will wonder "why did they do it this way?"
  3. The result of a real trade-off — there were genuine alternatives and you picked one for specific reasons
If any of the three is missing, skip the ADR. Use the format in ADR-FORMAT.md.
只有同时满足以下三个条件时，才建议创建ADR：
  1. 难以逆转——日后改变决策的成本很高
  2. 缺乏上下文会令人困惑——未来的读者会疑惑“他们为什么要这么做？”
  3. 是权衡后的结果——存在真正的替代方案，且你出于特定原因选择了其中一个
如果缺少任意一个条件，就不要创建ADR。使用ADR-FORMAT.md中的格式。