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 分析结果

一、行内标注

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

二、概念抽象汇总表

三、断层检查

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

四、设计建议

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

标注注意事项

• 一词多标：同一个词在不同上下文中可能属于不同维度。如"温度"单独出现时是 [D:属性] ，但"提取温度"中的"提取"是 [R:处理动作] 。

• 粒度把控：标注粒度以"对系统建模有意义"为准。虚词不标注。

• 隐含概念：注意文本中未明确说出但暗示的概念。如"实时接收"暗示了需要"流处理管道"或"消息队列"。

• 领域术语：对行业特有术语保持敏感，它们往往是核心实体或服务的直接来源。