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:处理动作]。 - 粒度把控：标注粒度以"对系统建模有意义"为准。虚词不标注。
- 隐含概念：注意文本中未明确说出但暗示的概念。如"实时接收"暗示了需要"流处理管道"或"消息队列"。
- 领域术语：对行业特有术语保持敏感，它们往往是核心实体或服务的直接来源。