# 领域建模（金蝶版）

参考 [domain-modeling](https://github.com/mattpocock/skills/blob/main/skills/engineering/domain-modeling/SKILL.md) 方法论，适用于需求讨论、术语澄清、架构决策记录。其他技能可通过 `read skill://_shared/kd-domain-modeling` 引用。

## 文件结构

```
项目根/
├── CONTEXT.md           ← 术语表（按需创建）
├── docs/
│   └── adr/
│       └── 0001-xxx.md  ← 架构决策（按需创建）
```

文件懒创建——有内容才写。没有新术语不建 CONTEXT.md，没有值得记录的决策不写 ADR。

## 核心行为

### 1. 术语挑战

当用户用了与 CONTEXT.md 已有定义冲突的术语时，立即指出来：

> 「你的术语表里'取消'定义为 X，但你刚才说的是 Y——是哪个？」

当用户用了模糊或过载的术语时，提议标准化的精确定义：

> 「你说的'账户'——是指客户还是用户？这是两个不同概念。」

### 2. 场景检验

领域关系讨论时，编造具体边界场景来拷打：

- 如果数据为空呢？
- 如果批量操作呢？
- 如果事务回滚了呢？
- 如果审核不通过呢？
- 如果同一个单被两个人同时操作呢？

### 3. 代码交叉验证

当用户说"这个操作是这么工作的"时，检查代码是否真的这么写。发现矛盾就指出来：

> 「你说部分取消是可以的，但代码里取消的是整单——哪个是对的？」

### 4. 更新 CONTEXT.md

术语一明确就立刻写入，不批量积攒。

**CONTEXT.md 只放术语定义**，不放实现细节、不放技术方案、不放需求描述。每条约 1-3 行：

```markdown
## 单据转换（Convert/BOTP）
定义：源单 → 下推/选单 → 目标单的字段映射过程。
别名：下推、推单、选单
```

### 5. 写 ADR（架构决策记录）

只在**同时满足**以下三条时才写：

1. **难回头**——选错后面改造成本高
2. **不读上下文看不懂**——外人看代码不知道为什么这么写
3. **真有取舍**——有多个方案选了其一

缺任何一条就跳过。格式：

```markdown
# ADR-N: 标题

## 上下文
背景和触发因素。

## 决策
我们决定做 X。

## 理由
为什么选 X 不选 Y 和 Z。
```

### 6. 放行条件

只有在术语表已确认、关键决策已记录、需求边界已清楚后，才放行进入编码阶段。