文章目录1. 先看全局：三个对象分别负责什么2. Solution：整套方案在内存中的总入口Solution 里最值得先看的数据它还负责调度整套流程3. ProjectInfo 与 Project：一个描述流程，一个让流程跑起来4. Project 的三组核心数据4.1 ModuleList：流程真正的执行清单4.2 ModuleDic：用空间换时间的模块索引4.3 OutputMap：插件之间传递数据的中转站5. 为什么 Project 绝不是“纯数据类”6. 创建一个流程时，框架究竟做了什么7. 从源码还能看到哪些设计信号信号一：方案级状态比较集中信号二：流程配置与运行状态混在同一个对象里信号三：名称在流程执行中具有业务意义信号四：当前单例实现不是线程安全单例8. 读完这一篇，至少要能回答这 5 个问题9. 一张图总结VM 框架数据结构系列（01）——方案层与流程层第一次打开一个体量较大的 WPF 项目，最容易犯的错就是从界面事件一路追进细节：窗口、按钮、插件、线程越看越多，却始终不知道“整套工程的数据到底放在哪里”。分析 VM 框架，可以先抓住两个类：Solution：管理整套方案的全局上下文；Project：承载并执行一个具体流程。它们构成了框架最上层的骨架。后续要理解模块、变量、数据流和持久化，都绕不开这组关系。本文不逐行翻译源码，而是回答 4 个更实用的问题：一套方案怎样容纳多个流程？当前流程怎样被选中和运行？流程里的模块与输出数据放在哪里？为什么Project不是一个普通的数据实体？先给结论：Solution决定“这套工程里有什么”，Project决定“其中一条流程怎样跑”。1. 先看全局：三个对象分别负责什么
