4. 模块内ViewModel状态定义：状态聚合根、不可变快照、单向数据流、本地状态作用域

4.1 边界定义：模块内状态管理四要素

模块内ViewModel的状态管理不是随意的属性集合，而是由四个紧密关联的架构要素构成的严格范式。这四个要素共同定义了“状态在模块内如何被定义、存储、变更和消费”的完整规则。

4.2 分层策略：四要素的层级结构

四要素在模块内部形成三层架构，每一层只与相邻层通信：

• 表现层（UI Layer）：仅消费不可变快照，通过事件触发状态变更。
• 状态管理层（State Layer）：持有状态聚合根，调度Reducer产生新快照。
• 作用域层（Scope Layer）：负责模块生命周期管理，确保状态在模块销毁时被彻底释放。

4.3 组件职责：各要素的交付物

下表明确了每个架构要素在具体实现中的交付产物：

4.4 数据流与控制流

在四要素框架下，数据流与控制流严格分离：

• 数据流：由聚合根向下游单向流动，经过不可变快照作用于UI。
• 控制流：由UI发起事件，经Reducer改变聚合根状态，驱动数据流更新。

信任链路遵循“以聚合根为圆心，向外辐射”的原则：任何外部模块或代理都不被信任直接访问聚合根，必须通过事件接口间接通信。

// 伪代码：Reducer 纯函数示例
fun reduce(state: StateAggregate, event: Event): StateAggregate {
    return when (event) {
        is Event.UpdateTodo -> state.copy(
            todos = state.todos.map { 
                if (it.id == event.id) it.copy(isDone = true) else it 
            }
        )
        else -> state
    }
}

4.5 选型权衡与风险点

4.6 落地步骤

1. 划定状态边界：明确模块内的状态集合，排除UI无关的中间状态。
2. 定义事件协议：使用密封类/枚举列出所有可能的状态变更事件。
3. 实现Reducer：编写纯函数，确保每个事件对应唯一的状态转换逻辑。
4. 创建不可变快照：在聚合根上暴露只读拷贝方法，或直接发布数据类副本。
5. 注入作用域：将模块生命周期作用域与ViewModel绑定，确保销毁时清理。

4.7 验收标准

• ✅ 模块内无法通过反射或强制转换修改聚合根内部状态。
• ✅ 任意两次相同的事件序列产生的UI快照在结构和值上完全一致。
• ✅ 模块销毁后，所有状态引用在GC root中不可达。
• ✅ 外部模块无法订阅或观察模块内部的状态变化，除非通过桥接接口。

4.8 四要素的信任关系与边界线

在模块内，四要素形成三条“不可逾越”的边界线：

• 模块边界（模块 vs 外部）：状态聚合根和本地作用域严格位于模块内部，外部只能通过桥接接口接收不可变快照，无法反向修改。
• 数据流边界（聚合根 vs 快照）：聚合根产生快照后，对原状态的控制权立即丧失；快照的消费者不能反向回写。
• 对象边界（ViewModel vs 其他类）：ViewModel本身不被视为状态的一部分，它只是作用域容器和Reducer调度器。