product-drd

name	product-drd
description	数据需求文档（DRD）编写技能。用户需要编写或评审 DRD 时使用，指导定义数据 schema、字段规范、枚举约束和数据关系，作为数据契约独立于实现。

product-drd

数据需求文档（DRD）编写技能。

核心定位

DRD 是一份业务决策记录，而不是技术实现说明。它记录业务概念由哪些数据构成、为什么这样设计、边界在哪、未来怎么发展。

字段表只是概念的一个侧面。DRD 的中心是业务概念本身，不是字段。

边界

• DRD 描述数据 schema，IXD 描述交互流程，ADD 描述技术实现
• 不写 API 接口、不写数据库表结构、不写代码逻辑
• 枚举值直接定义在 DRD 中，不依赖外部系统

经验

DRD 最常见的错误是写成"告诉开发者怎么实现"的技术文档。正确的 DRD 应该让读者理解"这个业务概念经历了什么才长成这样"。

例如，一个字段从单值变为数组、某个枚举从五档砍到三档——这些变更背后的业务决策才是一份 DRD 最有价值的内容。字段表本身只是快照。

文档结构

根 README.md

# DRD

| 文件 | 对应领域 | 说明 |
|------|----------|------|
| `xxx.md` | 领域名 | 数据模型 schema |

数据 Schema 文档

按数据实体组织，每个实体一个文件。格式规范如下：

# 业务概念名称

## 模型名`ModelName`

| 字段 | 类型 | 必填 | 默认 | 说明 |
|------|------|------|------|------|
| `id` | string | 是 | — | 唯一标识 |

字段说明列用一句话讲清楚"存什么"，不要写"怎么用"。

### 关键字段说明（可选）

对于需要解释设计理由的字段组合或复杂字段，用一级子章节展开。

## 示例

Fixture 路径：`src/assets/fixtures/xxx.json`

## 职责边界

以下职责在其他模型，不在本模型：

- **职责归属方** → 归属模型的职责。一句话解释为什么归它不归本模型。

## 未来待拓展

以下职责当前未分配，待定方案：

- **待定职责**：描述。

命名规范

• 文档标题：中文业务概念名，不加 Schema、Data 等后缀
• 模型名称：反引号包裹在标题中，如 ## 课时模型\Lecture``
• 文件名：英文小写，如 lecture.md

样式规则

• 层级扁平，不超过三级标题
• 枚举不列表，行内写死值即可："初级"、"中级"、"高级"三档
• 无数据关系图（ASCII 关系图），关系和归属在设计说明/职责边界中用文字表达
• 无变更记录表
• 无独立的数据约定章节，约定融入字段说明
• 示例（Fixture）一行文字带过，不用代码块包裹路径

审查清单

• 标题是中国业务概念名，不是英文技术名
• 字段表讲清了"存什么"，没有"怎么用"
• 枚举值行内定义，不独立列表
• 数据关系用文字说明，不用 ASCII 图
• 无可删除的技术实现描述（API、数据库、代码逻辑）
• 职责边界清晰：在本模型的和不在的都有说明
• 有经验/决策记录（为什么长这样，而不是只记录长什么样）
• 无变更记录表
• Fixture 路径已标注，一行文字

与其他文档的关系

BRD → PRD → IXD → DRD → ADD，QA 验证所有层。

• PRD 定义功能需求，DRD 定义功能依赖的数据
• IXD 描述用户操作，DRD 定义操作背后的数据结构
• ADD 做技术选型和架构，DRD 提供数据定义作为输入