接了个大活，要把公司内部好几条业务线的订单系统统一抽取出来，做成一个订单平台，支撑目前多条业务线的订单体系，同时也要求可以灵活扩展，快速支持之后的新业务。
谈到订单，基本上是大部分公司业务系统中没办法绕过的一环，而订单最关键的是什么？个人认为是其生命周期，其中订单的状态变更 更是需要仔细设计、考虑的点。如果对于单一稳定的业务，不太建议使用状态机来实现，引入了不少复杂度。但是如果业务经常变化，业务模式又多种多样，那么前期引入状态机引擎就太值得了，好的设计可以避免后期很多工作量产生。
关于状态机引擎的选型，其实目前市面上有不少框架，github上按照statemachine关键字搜索可以出来好多结果。考虑到资料完备情况、与项目的集成容易程度、框架是否尚在维护等条件，这里选择spring statemachine。其实在segmengfault中有一篇文章在推荐squirrel，只是目前spring statemachine已经又进一步完善，足以满足我的需要，而且在引擎实例持久化方面更是提供了比较完备的解决方案，所以还是继续选择spring家族的产品。这篇比较的文章参见：https://segmentfault.com/a/1190000009906317
看spring的产品，首先看其quickstart项目，然后根据reference做字典式学习，
- 官网：http://projects.spring.io/spring-statemachine
- 对应的reference：https://docs.spring.io/spring-statemachine/docs/1.2.8.RELEASE/reference/htmlsingle
- 以及对应的源码 & samples：https://github.com/spring-projects/spring-statemachine
另外，目前网上基本上所有的spring statemachine教程都是脱胎于官网的简单教程及@翟永超 的一篇博文（http://blog.didispace.com/spring-statemachine/），而且无一例外都是基于spring boot的。对我目前的项目来说确实并不是太适用，所以以下内容是基于普通spring + spring statemachine进行实现的，并未引入spring boot，介意的可以节省点时间，不用继续看下去了，生命苦短，没必要浪费哈！
状态机定义-相关概念
先从状态机的定义入手，StateMachine<States, Events>，其中：
- StateMachine：状态机模型
- state：S-状态，一般定义为一个枚举类，如创建、待风控审核、待支付等状态
- event：E-事件，同样定义成一个枚举类，如订单创建、订单审核、支付等，代表一个动作。
一个状态机的定义就由这两个主要的元素组成，状态及对对应的事件（动作）。
状态机-相关概念
- Transition: 节点，是组成状态机引擎的核心
- source：节点的当前状态
- target：节点的目标状态
- event：触发节点从当前状态到目标状态的动作
- guard：起校验功能，一般用于校验是否可以执行后续action
- action：用于实现当前节点对应的业务逻辑处理
举个简单的例子：
builder.configureTransitions() -- 配置节点
.withExternal() //表示source target两种状态不同
.source(CREATE) //当前节点状态
.target(WYD_INITIAL_JUMP) //目标节点状态，这里是设置了个中间状态
.event(BizOrderStatusChangeEventEnum.EVT_CREATE) //导致当前变化的动作/事件
.action(orderCreateAction, errorHandlerAction) //执行当前状态变更导致的业务逻辑处理，以及出异常时的处理
补充说明：
- withExternal 是当source和target不同时的写法，如上例子
- withInternal 当source和target相同时的串联写法，比如付款失败时，付款前及付款后都是待付款状态
- withChoice 当执行一个动作，可能导致多种结果时，可以选择使用choice+guard来跳转
目前我主要使用的就是这三种，当然如果有更复杂的情况，还有withLocal\withJunction等各种写法，但是：当你对一项技术并不是那么了解时，先尽可能的用简单的实现来处理你的业务，出现问题的可能性最小，后续可以再慢慢扩展。
注意：
- 上述代码event之后并没有设置guard，代表默认会执行对应action。
- 这里的orderCreateAction及errorHandlerAction都是使用spring注入进来的业务bean。
稍微复杂的节点配置
接上面的withExternal，下面是使用choice做了一个分支选择，代码如下：
.and() // 使用and串联
.withChoice() // 使用choice来做选择
.source(WYD_INITIAL_JUMP) // 当前状态
.first(WAIT_REAL_NAME_AUTH, needNameAuthGurad(), needNameAuthAction) // 第一个分支
.last(WAIT_BORROW, waitBorrowAction) // 第二个分支
说明：
- 多个节点之间使用and()串联
- 注意，withChoice没有对应的event，所以依赖上一个节点的event，只要source是WYD_INITIAL_JUMP，就会自动执行当前choice transition
- withChoice没有对应的target，只有几个选择分支
- first/then/last 类似于 if--else if--else ，then可以不设置，但是last一定要有，否则会报错
- needNameAuthGurad() 用于判断是否走当前分支，返回true时选择当前分支，返回false走下面分支
- last中其实是省略了一个guard的实现，默认为true，意味着如果不走first分支，就会走last分支。
- withChoice其实是个PseudoState，也就是伪状态或瞬时状态，会马上跳转到下面的分支流程中。
如果是复杂一点的流程，比如有子状态，那么就有一个region的概念，region-区域，表示有一系列状态，这些状态有相同的父状态。
好啦，基本上项目中用到的核心概念就先到这里，下一节会讲下状态机引擎的持久化处理。
