cruldra/dri-text-analysis

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 交叉验证：

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

完整案例

原始文本

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