数据驱动 vs 流程驱动：前端与 Flutter 的两种架构主线

当项目还小时，我们讨论的是：

「这个页面怎么写？」

当项目变复杂，真正重要的问题会变成：

👉 这个系统到底是靠"数据关系"在运转，还是靠"业务流程"在运转？

这背后，其实对应着两条非常清晰、也非常通用的系统架构主线：

👉 数据驱动系统（Data-Driven）

👉 流程驱动系统（Process-Driven）

这两条主线，贯穿了前端、Flutter、甚至后端与系统工程。

一、先说结论（整篇文章的核心）

👉 数据驱动解决"系统怎么联动"

👉 流程驱动解决"系统怎么走"

数据驱动关心：谁依赖谁、谁由谁算出来
流程驱动关心：发生了什么、系统处在哪个阶段、接下来允许做什么

这不是"框架差异"，而是系统建模方式的差异。

二、数据驱动：系统靠"关系"运转

1️⃣ 什么是数据驱动系统？

数据驱动系统的核心模型是：

复制代码

C = f(A, B)
D = g(C)
UI = h(State)

你描述的是关系，不是步骤。

你不写：

"当 A 变了，去更新 C，再去更新 D，再刷新 UI。"

你只写：

"C 依赖 A、B；D 依赖 C；UI 依赖 State。"

系统负责：

依赖收集
自动重算
自动刷新
生命周期管理

👉 这是依赖系统 / 响应式系统。

2️⃣ 前端里的数据驱动

前端真正"数据驱动视图"的核心不是 Redux，而是：

Vue reactive / computed
React state / hooks
Solid signals
Svelte reactivity

它们解决的是：

👉 数据变了，谁该更新。

3️⃣ Flutter 世界里的数据驱动

在 Flutter 中，典型的数据驱动系统是：

Riverpod
Provider
Signals

例如：

Dart 复制代码

final totalPriceProvider = Provider((ref) {
  final items = ref.watch(cartProvider);
  final coupon = ref.watch(couponProvider);
  return calc(items, coupon);
});

你描述的是：

👉 totalPrice 由 items 和 coupon 决定。

这就是纯数据驱动建模。

4️⃣ 数据驱动系统最擅长什么？

派生状态 / 组合状态
自动联动
依赖管理
生命周期托管
数据驱动视图

本质关键词只有一个：

👉 算

三、流程驱动：系统靠"事件"运转

1️⃣ 什么是流程驱动系统？

流程驱动系统的核心模型是：

Dart 复制代码

(State, Event) -> NewState

系统被描述为：

有哪些状态
会发生哪些事件
在什么状态下发生什么事件，会走向什么新状态

👉 这是状态机 / 行为系统。

2️⃣ 前端里的流程驱动

典型代表：

Redux
Vuex
Pinia
Elm / MVI

它们的共同点是：

所有变化必须通过 Action
状态迁移集中管理
单向数据流

例如 Redux：

Dart 复制代码

Action -> Reducer -> State -> View

这是流程建模，不是视图建模。

3️⃣ Flutter 世界里的流程驱动

Flutter 中最典型的是：

BLoC

模型非常纯粹：

Event -> Bloc -> State

你建模的不是"数据关系"，

而是：

👉 业务流程。

4️⃣ 流程驱动系统最擅长什么？

登录 / 支付 / 向导
列表复杂交互
设备控制
协议交互
并发 / 取消 / 防重

本质关键词只有一个：

👉 走

四、这不是对立，是分工

真实系统几乎永远是：

Dart 复制代码

底层：数据驱动系统（结构/联动）
上层：流程驱动系统（行为/约束）

前端如此：

reactive 负责数据联动
redux 负责业务流程

Flutter 也是：

Riverpod 管数据结构
BLoC 管业务流程

五、一个非常直观的类比

🧮 数据驱动系统像 Excel

Dart 复制代码

C = A + B
D = C * 2

你不关心"什么时候算"，

系统负责传播。

🎮 流程驱动系统像游戏规则

Dart 复制代码

Idle + Start   -> Loading
Loading + Ok   -> Success
Loading + Err  -> Error

你关心的是：

👉 发生了什么

👉 现在在哪

👉 接下来去哪

六、为什么只靠"数据驱动"不够？

因为真实系统里有：

多事件源
强流程约束
状态阶段爆炸
并发和打断
安全与权限

这些问题，本质不是"怎么算"，

而是：

👉 怎么走。

七、如何在工程中落地？

✅ 当你的模块主要在"算"

数据组合
自动联动
派生状态
依赖管理

👉 数据驱动（Riverpod / reactive）

✅ 当你的模块主要在"走"

状态阶段很多
规则很多
事件很多
并发很多

👉 流程驱动（BLoC / Redux / Vuex）

八、把这两条主线统一起来

现在你可以用同一套坐标系理解：

范式	前端	Flutter	系统模型
数据驱动	reactive / signals	Riverpod	依赖图
流程驱动	Redux / Vuex	BLoC	状态机

九、整篇文章一句话总结

数据驱动系统解决"系统如何联动"，

流程驱动系统解决"系统如何运行"。

或者更工程一点：

Riverpod 管"算"，

BLoC 管"走"。