---
name: domain-modeling
description: 用于业务领域概念与术语建模（与管理数据库表结构的 data-modeling 相对）、维护 `CONTEXT.md` 及 ADR。
---

# 领域建模

在设计过程中主动构建并完善项目的领域模型。这是一项*主动*的工作：质疑术语、构造边界场景，在术语和决策确定的当下就记录下来。

只*读取* `CONTEXT.md` 获取词汇不属于本 skill，任何 skill 都可以这样做。本 skill 用于修改领域模型，而不只是使用它。

## 文件结构

大多数仓库只有一个上下文：

```
/
├── 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-MAP.md` 中的每个上下文默认对应代码中的一个业务模块。讨论上下文怎么划分、模块之间如何交互时，读取 `codebase-design` skill 目录下的 [BUSINESS-MODULES.md](../codebase-design/BUSINESS-MODULES.md)。

文件按需创建，有内容要写时才创建。没有 `CONTEXT.md` 时，在第一个术语确定时创建；没有 `docs/adr/` 时，在需要第一条 ADR 时创建。

## 会话中的做法

### 对照术语表提出质疑

用户使用的词与 `CONTEXT.md` 中已有的定义冲突时，立即指出。例如：“术语表把‘取消’定义为 X，但你现在的意思似乎是 Y。应该以哪个为准？”

### 澄清模糊的说法

用户使用含糊或一词多义的词时，提出一个准确的标准术语。例如：“你说的‘账户’，指的是客户还是用户？这是两个不同的概念。”

### 用具体场景检验

讨论领域关系时，用具体场景做压力测试。构造能触及边界的场景，让用户把概念之间的界线说清楚。

### 与代码交叉核对

用户描述某件事如何运作时，检查代码是否一致。发现矛盾时指出：“代码会取消整个订单，但你刚才说可以部分取消。哪个是对的？”

### 就地更新 CONTEXT.md

术语一确定，就立即更新 `CONTEXT.md`。逐个记录，不要攒到最后一起写。格式见 [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md)。

`CONTEXT.md` 只记录领域术语，不包含实现细节。它是术语表，不是规格、草稿或实现决策的存放处。

### 谨慎提议 ADR

只有以下三个条件同时满足时，才提议写 ADR：

1. **难以逆转**：以后改变决定的代价不小
2. **缺少上下文时会令人意外**：未来的读者会疑惑“为什么要这样做？”
3. **确实存在取舍**：有真正可行的备选方案，基于具体理由选择了其中一个

任一条件不满足就不写。格式见 [ADR-FORMAT.md](./ADR-FORMAT.md)。

### 指出与 ADR 的冲突

你的产出与已有 ADR 矛盾时，明确指出，而不是悄悄覆盖：

> _与 ADR-0007（订单事件溯源）矛盾，但值得重新讨论，因为……_