- 背景分析
业务模块在开发时，除了需要考虑内部逻辑以外，还有与其他模块的协作配合。
模块任务实现时，依赖协作检查多是根据业务定制手写，而没有标准框架。
缺点：可靠性差，扩展和调整依赖关系时，这部分代码的修改也是大问题，后期追溯和阅读也不方便。
期望：通过框架能够对这部分任务和代码实现标准化和自动化。
任务分两种：
- 周期任务。如：打羽毛球。
- 单次任务。如：接力赛。
那么，系统中各模块怎么输入他们之间协作时的状态依赖？
- 状态依赖的输入
右侧是系统模块间状态依赖，体现模块间的协作设计。
左侧是模块运行时的环境，通过右侧配置解析而得，以简化状态和依赖关系搜索效率。
- 应用场景
复杂系统一般都有大量的模块，共存和协作问题一直是复杂且出问题比较多的场景。
不管是应用层多模块开发还是底层系统设计，都可以通过这个框架进行协作和共存设计，
运行时作为公共任务隐藏在模块调度执行中。
模块专注于子程序开发和工作流设计。
上图左边是当前模块的状态，由架构师基于模块的职责设定和模块间的协作设计而来。
上图右边是每个状态对应的子程序工作流。
上图是各个状态的工作流，左边是任务执行条件，右边是子程序，可以有多个子程序。