利用状态机使得系统设计透明

写在前面

在整个交易平台中，会有多个系统的业务逻辑随着订单的状态变更有不同的业务规则转换，如果在系统中不对状态变更所引发逻辑做较好的设计的话，未来系统这部分代码必将越来越难以维护，变为整个系统腐朽的源头。

有限状态机

订单状态可能是“已下单” -> "已支付" -> "取消" -> "完成"等，这些状态是由某个或某几种动作所触发变更的。

针对这种有限范围内状态变更可以引入“有限状态机”（FSM）进行设计。

我们举个例子，稍晚复杂些，其他状态流转设计可以参考设计：以设备通过GPRS连接到控制中心，通过接受控制中心的指令来改变自身的运行状态，我们可以抽象出系统提供控制设备的API：

状态流转图：

整个设备拥有多个可能的状态，并且在特定状态下接受正确的指令后可以迁移到指令的目标状态，状态机有一个向量图，状态为端点，操作为边，一个状态端点在特定操作的驱动下迁移到另一个状态端点。

针对状态变更流转图可以得到如下问题：

1. 一个状态端点可以由哪些状态端点变迁而来？
2. 一个状态端点可以变迁到哪些状态端点去？