文章

横向按技术职责分层，纵向按业务域切分，再用一个显式装配层把两者接起来。

本文关注的重点不是下载接口本身，而是批量下载背后的任务调度、状态机边界和 Native 协同。下载只是这套架构当前的落地场景，这套设计解决的问题则更通用：一批异步任务如何在复杂边界下持续、可控、可恢复地执行。

这次做 FlowEngine 的背景，是想把现有 App 里的设备添加流程先治理起来，同时为后续其他复杂流程预留一套可复用的调度模型。

配置树提供的是一条中间路线：页面结构用配置描述，节点依赖用 `features` 声明，业务判断放回 fetch 和交互逻辑，渲染层只消费最终状态。

这一步解决的是第一层边界：设备这个业务实体应该由谁管理，状态应该从哪里读，业务动作应该从哪里进。

从 `Manager` 到 `Module`，最大的变化不是类名，而是职责边界被重新立起来了。

把面向页面的 BFF 看成一条服务端流水线。请求先经过静态与模块层，再进入全站中间件，命中具体页面后做数据聚合，最后由渲染模板决定如何输出 HTML、流或 CSR fallback。

不把商户差异当成零散条件分支处理，而是把它当成需要治理的对象。

不再是“提供更多组件”，而是“提供一套页面生产系统”。标题里说“抛弃组件库”当然有一点传播意味，真实情况并不是不要组件，而是把组件从最终交付物，降级成页面平台里的基础物料。