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:

Hard to reverse — the cost of changing your mind later is meaningful
Surprising without context — a future reader will wonder "why did they do it this way?"
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：

难以逆转——日后改变决策的成本很高
缺乏上下文会令人困惑——未来的读者会疑惑“他们为什么要这么做？”
是权衡后的结果——存在真正的替代方案，且你出于特定原因选择了其中一个

如果缺少任意一个条件，就不要创建ADR。使用ADR-FORMAT.md中的格式。