系统设计方案是如何落地的
系统实现的过程就是不断抽象的过程，即业务建模，行为建模，系统架构，数据建模的过程，通过四层抽象，将实际业务场景具象化为信息化管理系统（即将场景转化为计算机语言的过程），抽象的具体过程如下：
而状态图又可以决定业务流程的合理性和业务规则的严谨性。（数据库设计包含业务建模、调用逻辑梳理、存储结构设计三个大步骤，具体偏技术，不班门弄斧，感兴趣的可以自行百度）
什么是状态图
状态图是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。
--百度百科
通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外状态转换图还指明了作为特定事件的结果系统将做哪些动作（例如，处理数据）。因此状态转换图提供了行为建模机制
--软件工程导论
状态图的常用图例如下：
eg支付单为支付过程中的行为信息聚合实体，简单的支付状态图如下：
特别是在复杂的业务流程中，抽象聚合操作场景流程，将业务进度抽象为状态的变化，业务规则转化为状态变化规则，梳理出来状态图，直观的看出某个实体的生命周期变化过程。而对于系统使用者，显示的是操作的实体为期望到达的最终结果所要发生的每一步操作（动作）和伴随操作所达到的阶段性成果以及下一步的指引。
eg订单流程：
具体设计过程
以在线教育订单为例
1、抽象主要状态，即正序状态
2、根据对象分类并补充细化子状态和异常状态
2.1根据对象分类；同时注意，子流程较长的，增加过程状态；
2.2补充异常状态
3.输出状态图及状态逻辑
对应业务流程检查，看是否需要拆分两个状态图（有可能不同业务线，状态顺序不同）；
子状态的起始状态和结束状态与主状态关联；
状态之间可相互转化；与其他状态无转化关系的“状态”去除（感兴趣的可以研究下，在状态设计时，为什么支付状态会有“支付超时”，在设计任务状态时，更倾向于将“超时”加入到SLA中，作为标签，而不是直接作为人物状态）
优化状态文案；
最后一步，补充状态转化逻辑，再次review逻辑，看是否有遗漏状态和逻辑bug
