02-业务架构与数据流转

相比于 01-总体架构设计关注“代码和技术组件怎么堆叠”，本文档重点阐述“业务数据如何在这个系统里流动”。

在 AIOT 这个同时具备人工作业（Ops）和硬件交互（IoT）属性的系统中，搞懂业务架构，就是搞懂这两者怎么联动。

🔗 关联阅读：

具体 Ops 流转细节，请看：../02-Ops领域/01-工单生命周期与状态机.md

具体 IoT 数据处理，请看：../03-IoT领域/00-IoT领域总览.md

1. 业务高层视图 (Business Architecture)

整个平台的业务可以抽象为「三环模型」：感知环、调度环、执行环。

flowchart LR
    subgraph 感知环 ["感知环 (Trigger)"]
        direction TB
        ManualEvent["人工上报<br/>(巡检异常/主动报修)"]
        IoTEvent["设备感知<br/>(阈值告警/离线预警)"]
    end

    subgraph 调度环 ["调度环 (Brain)"]
        direction TB
        RuleEngine["规则引擎<br/>(过滤/转化)"]
        Dispatch["派单引擎<br/>(抢单/派单/排班)"]
        RuleEngine --> Dispatch
    end

    subgraph 执行环 ["执行环 (Action)"]
        direction TB
        OpsTask["人工执行<br/>(工单/保洁/安保)"]
        IoTAction["设备控制<br/>(反向指令下发)"]
    end

    ManualEvent --> Dispatch
    IoTEvent --> RuleEngine

    Dispatch --> OpsTask
    RuleEngine --> IoTAction

为什么这样拆分？

触发源可以是人，也可以是设备：保安巡逻发现水管爆裂（人工上报），或者水压传感器触发阈值（设备感知）。
调度是统一的大脑：平台接收到事件后，需要决定是派人去修（生成工单发给移动端），还是直接给另外一台设备发指令关阀门（控制指令下发）。
执行方式隔离：人的闭环在 Ops领域（抢单、拍照、核验）；设备的闭环在 IoT领域（发指令、等 ACK 报文）。

2. 核心数据流转链路

理解了三环模型后，以下是系统最核心的三条数据数据链路（Data Flow）。开发人员在写代码或联调时，必须清楚自己的接口位于哪条链路上。

链路 A：纯人工业务闭环 (The Ops Flow)

这是目前阶段最成熟的基本盘链路。

发起：Web 后台运营人员创建一个【保洁任务】，或者保安在移动端上报一个【异常工单】。
分配：后端根据配置的抢单规则或固定排班规则，将任务分配给特定的移动端账号。
触达：移动端通过轮询或消息推送收到任务。
执行与完工：现场人员到达位置（上传定位），完成工作（上传照片），并在移动端点击【完工】。
归档：数据流回后端，触发工单状态变更为【已完成】，可供数据看板进行绩效统计。

链路 B：纯设备数据闭环 (The IoT Flow)

这是下一阶段的建设重点。

采集：传感器设备通过 MQTT 协议将遥测数据（Telemetry）推送到网关。
解析：后端 module-iot 获取 payload，根据设备绑定的【物模型】解析出具体的属性值（如温度=25℃）。
存储与判断：数据落地到时序数据库或 MySQL 中，并经过【规则引擎】判断是否触发预设的告警规则。
控制：如果无需人工介入，Web 控制台或规则引擎可以直接向设备下发控制指令（如【打开风扇】），等待设备回复执行结果。

链路 C：设备与人工的交叉联动 (The Hybrid Flow)

这是本系统最终要达成的终极壁垒，即打破软硬件孤岛。

sequenceDiagram
    participant Device as IoT设备
    participant Rule as 规则引擎 (IoT)
    participant Ticket as 工单系统 (Ops)
    participant Worker as 移动端 (员工)

    Device->>Rule: 1. 上报烟雾超标告警 (MQTT)
    activate Rule
    Rule->>Ticket: 2. 触发联动，调用内部接口生成紧急工单
    deactivate Rule
    
    activate Ticket
    Ticket->>Worker: 3. 推送紧急【安保巡查工单】
    deactivate Ticket
    
    activate Worker
    Worker->>Device: 4. 员工现场确认并可通过 App 强切设备电源
    Worker->>Ticket: 5. 提交工单处理结果，拍照留存
    deactivate Worker

3. 跨域业务边界准则

为了防止后期代码变成一团乱麻，业务边界必须死守以下红线：

工单系统不关心具体是什么硬件：module-ops 只能看到一个通用的“事件源 ID”和“故障描述”，它不需要去解析 MQTT 报文。解析的工作必须在 module-iot 内完成，转化成通用事件后再推给 Ops。
设备系统不关心是谁在排班：module-iot 触发告警后，只负责抛出“设备异常事件”，由 module-ops 决定这个事件是派给保洁张三还是安保李四。
数据冗余的容忍度：为了解耦，允许在工单表里冗余存储当时的设备名称和位置信息，而不是每次查询工单都去 join 设备表。

更新时间：2026-04-06

5.1 KiB Raw Blame History Unescape Escape