DRI 文本分析法 (Data-Rule-Interaction Text Analysis)

一种将自然语言业务需求降维拆解为系统设计基石的分析标准。本质上是在做需求工程中的领域语言（Ubiquitous Language）提取，对后续的面向对象设计、数据库建模、接口设计乃至代码脚手架生成都极具价值。

何时使用此技能

当用户有以下行为时使用此技能：

提供了一段业务需求描述，需要从中提炼系统的数据模型、业务规则和交互边界
说"帮我分析一下这段需求"或"把这段文字拆解成系统设计"
说"对项目进行DRI分析"或"用DRI方法解析需求文档"
想在动手写代码前，先把需求文档转化为结构化的架构抽象
需要检查需求是否存在断层（有数据没交互、有交互没规则等）
正在做领域建模，需要从自然语言中提取实体、服务、接口等概念
想把长篇需求文档拆解为可分配给不同技术组件的开发任务

核心概念

三元抽象模型

软件系统的核心目的是：接收外部指令，处理信息，并保存状态。 DRI 模型用三个维度完整覆盖：

┌──────────────────────────────────────────────┐
│                                              │
│   触发(I) ──→ 执行(R) ──→ 读写(D)           │
│                                              │
│   反馈(I) ←── 回调(R) ←── 变化(D)           │
│                                              │
└──────────────────────────────────────────────┘

数据是体，规则是法，交互是相。

此模型与经典 ECB 模式（Entity-Control-Boundary）高度契合：

DRI 概念	ECB 模式	六边形架构	Clean Architecture
数据 (D)	Entity	Domain Model	Entities
规则 (R)	Control	Application Service	Use Cases
交互 (I)	Boundary	Port / Adapter	Interface Adapters

[D] 数据 (Data) — 系统的"状态"与"资产"

回答 "系统里有什么"。

词性特征：名词、名词短语、特定数值、状态枚举词。
识别依据：它是否代表了系统中需要被"记住"、"存储"、"查询"或"更新"的信息？
子分类：
- 实体 (Entity)：具有唯一标识和生命周期的业务对象（如 监控节点、画面帧）
- 属性 (Attribute)：实体的具体特征值（如 温度数值、运行状态）
- 常量/配置 (Constant)：阈值、枚举值等（如 80度、异常）
- 流/资源 (Stream/Resource)：瞬态或持久化的数据资源（如 视频流、现场截图）
- 消息 (Message)：系统间传递的数据载体（如 报警通知）
典型词汇：记录、数值、状态、属性、配置、快照、列表、模型、上下文

[R] 规则 (Rule) — 系统的"引擎"与"法则"

回答 "系统如何运作"。

词性特征：表示计算、判断、比较的动词，条件关联词。
识别依据：它是否定义了事物变化的条件？是否包含 If-Then 逻辑、数学运算或约束？
子分类：
- 条件判断 (Condition)：If-Then 逻辑的触发条件（如 如果...连续3秒超过...）
- 阈值比较 (Threshold)：数值比较运算（如 超过、大于、等于）
- 时间约束 (Temporal)：涉及时间窗口的判定（如 连续3秒、每隔5分钟）
- 领域服务 (Domain Service)：封装的复杂业务逻辑链（如 火灾智能推理逻辑）
- 状态变更 (State Transition)：实体状态的转换动作（如 更新为异常）
- 数据处理 (Processing)：数据转换、提取、计算（如 提取温度、计算平均值）
典型词汇：如果、判断、超过、匹配、计算、过滤、验证、触发、转换

[I] 交互 (Interaction) — 系统的"边界"与"触角"

回答 "系统由谁触发，又影响谁"。

词性特征：表示动作转移、跨越边界的动宾短语，外部系统/物理设备的专有名词。
识别依据：它是否涉及信息的输入/输出（I/O）？是否是系统与外部世界的触点？
子分类：
- 入站 (Inbound)：外部 → 系统的数据流入（如 接收视频流、用户点击）
- 出站 (Outbound)：系统 → 外部的数据流出（如 发送通知、渲染画面）
- 外部角色 (Actor)：与系统交互的人或第三方（如 管理员、玩家）
- 外部设备/渠道 (Channel)：I/O 的物理或逻辑载体（如 摄像头、企业微信、API 接口）
典型词汇：点击、接收、发送、接口、推送、显示、上传、下载、渲染

[O] 其它 (Other)

连词、介词、代词等语法结构词（如"的"、"地"、"将"、"和"），在系统建模中无实际抽象价值，标注时忽略。

分析流程

第一步：行内逐词标注

对原始文本逐词或逐词组进行拆解，在关键短语后紧跟方括号标签。

标注语法：词汇[标签:子分类]

标签取值：

D:实体 D:属性 D:常量 D:流数据 D:消息 D:状态枚举
R:条件起点 R:阈值比较 R:时间约束 R:领域服务 R:状态变更 R:处理动作
I:输入设备 I:输入动作 I:输出渠道 I:输出动作 I:外部角色 I:接收端

第二步：概念抽象汇总表

将标注结果合并提炼，输出为结构化表格：

抽象维度	提取出的具体概念	系统设计映射	备注/设计建议
数据 (Data)	从标注中提取的所有 D 标签内容	领域模型/实体、配置项、持久化表设计	瞬态 vs 持久化、可配置 vs 硬编码
规则 (Rule)	从标注中提取的所有 R 标签内容	核心算法、领域服务、状态机	需重点编写单元测试的部分
交互 (Interaction)	从标注中提取的所有 I 标签内容	入站网关、出站网关、UI 组件	容错、重试、并发处理

第三步：断层检查

完成表格后执行 D-R-I 交叉验证：

数据无交互：存在数据但没有任何交互去创建/修改/读取它 → 需求可能遗漏了输入输出。
交互无规则：存在交互（如接收数据）但没有规则去处理 → 需求可能遗漏了业务逻辑。
规则无数据：存在规则但没有操作的目标数据 → 规则可能是冗余的或数据定义缺失。
孤立实体：某个数据实体既不被规则引用，也不通过交互暴露 → 可能是过度设计。

完整案例

原始文本

"监控系统通过摄像头实时接收视频流，提取当前画面帧的温度数值。如果温度连续3秒超过80度，则触发火灾智能推理逻辑，系统自动通过企业微信向管理员发送包含现场截图的报警通知，并在数据库中将该监控节点的运行状态更新为异常。"

步骤一：行内标注

监控系统[I:接收端] 通过摄像头[I:输入设备] 实时接收[I:输入动作] 视频流[D:流数据]，提取[R:处理动作] 当前画面帧[D:实体] 的温度数值[D:属性]。如果[R:条件起点] 温度[D:属性] 连续3秒[R:时间约束] 超过[R:阈值比较] 80度[D:常量]，则触发[R:状态变更] 火灾智能推理逻辑[R:领域服务]，系统自动通过企业微信[I:输出渠道] 向管理员[I:外部角色] 发送[I:输出动作] 包含现场截图[D:流数据] 的报警通知[D:消息]，并在数据库中将该监控节点[D:实体] 的运行状态[D:属性] 更新为[R:状态变更] 异常[D:状态枚举]。

步骤二：概念抽象汇总表

抽象维度	提取出的具体概念	系统设计映射	备注/设计建议
数据 (Data)	视频流、画面帧、温度数值	领域模型：`VideoFrame`, `Temperature`	视频流属于瞬态内存数据，画面帧可能需要缓存
	80度（阈值常量）	配置项：`ALARM_TEMP_THRESHOLD = 80`	应设计为可配置参数，而非硬编码
	报警通知、现场截图	消息/资源：`AlarmMessage`, `ImageResource`	截图需持久化至对象存储，通知记入日志
	监控节点、运行状态、异常	持久化实体：`MonitorNode (Status: Normal/Error)`	对应数据库中的节点表及状态枚举字段
规则 (Rule)	提取（温度）	数据处理：图像识别/传感器数据解析算法	将非结构化数据转化为结构化数据
	如果...连续3秒超过...	推理引擎/状态机：时序数据滑动窗口判断	核心业务规则，需重点编写单元测试防误报
	触发火灾智能推理逻辑	领域服务：`FireReasoningService`	封装复杂的判定链条
	更新为（异常状态）	状态变更：`Node.setStatus(ERROR)`	确保状态变更的原子性和一致性
交互 (Interaction)	摄像头、接收	入站网关：视频流接收端口/硬件驱动	需考虑高并发与网络延迟的容错边界
	企业微信、管理员、发送	出站网关：企业微信 Webhook API 客户端	需处理网络调用失败的重试机制

步骤三：断层检查

✅ 所有数据均有对应的规则进行处理
✅ 所有交互均有对应的规则进行衔接
✅ 所有规则均有明确的数据操作对象
⚠️ 潜在遗漏：未提及"报警通知"的持久化存储（是否需要记录历史报警？）

输出模板

分析完成后，按以下结构组织输出：

## DRI 分析结果

### 一、行内标注

> [在此放置标注后的原始文本]

### 二、概念抽象汇总表

| 抽象维度 | 提取出的具体概念 | 系统设计映射 | 备注/设计建议 |
|---------|----------------|------------|-------------|
| **数据 (Data)** | ... | ... | ... |
| **规则 (Rule)** | ... | ... | ... |
| **交互 (Interaction)** | ... | ... | ... |

### 三、断层检查

- [x] / [ ] 数据覆盖检查
- [x] / [ ] 规则覆盖检查
- [x] / [ ] 交互覆盖检查
- ⚠️ [列出发现的遗漏或冗余]

### 四、设计建议

[基于分析结果给出的架构层面建议]

标注注意事项

一词多标：同一个词在不同上下文中可能属于不同维度。如"温度"单独出现时是 [D:属性]，但"提取温度"中的"提取"是 [R:处理动作]。
粒度把控：标注粒度以"对系统建模有意义"为准。虚词不标注。
隐含概念：注意文本中未明确说出但暗示的概念。如"实时接收"暗示了需要"流处理管道"或"消息队列"。
领域术语：对行业特有术语保持敏感，它们往往是核心实体或服务的直接来源。

dri-text-analysis