一直以来，总觉得ssm不够灵活，主要原因是没找到为状态机指定状态的方式，也就意味着状态机引擎实例必须要跟对应的业务数据一起持久化，虽然ssm提供了多重持久化的方式，依然觉得有点不爽。最近又回过头去啃了

测试代码弄了个全集的测试代码，如下：存在逾期、部分还款从放款到全部还款，不存在逾期及部分还款构造订单变化请求，私有方法从制定状态构造状态变化请求这里使用junit，模拟整个订单的生命周期，发送对应的事

说明前面基本上涵盖了一个项目中配置简单状态机的相关实现，不过还有一个关键点，就是外部代码如何调用状态机，以及如何让状态机的持久化与业务逻辑代码在同一个事务中，避免状态机中状态与实际订单中不一致，造成脏

背景上文说到BizManager的实现，其实整体看，这块东西跟springstatemachine并没有什么关系，纯粹是个人写的收不住了，把近期的一些东西整理下。对这部分不感兴趣的可以跳过，直接看下一

状态机配置状态机配置有两种方式，创建config类，实现StateMachineConfigurer（或者根据SE的不同，直接继承其子类StateMachineConfigurerAdapter、En

背景这期说下状态以及对应事件的相关设计，这部分内容是后续状态机相关的配置的基础，其中有些设计在实现的时候来回修改了几版，还是挺考验细节设计的。状态变迁状态机是为了解决订单的状态变迁问题，为了方便理解，

背景每次用到的时候新创建一个状态机，太奢侈了，官方文档里面也提到过这点。而且创建出来的实例，其状态也跟当前订单的不符；springstatemachine暂时不支持每次创建时指定当前状态，所以对状态机

接了个大活，要把公司内部好几条业务线的订单系统统一抽取出来，做成一个订单平台，支撑目前多条业务线的订单体系，同时也要求可以灵活扩展，快速支持之后的新业务。谈到订单，基本上是大部分公司业务系统中没办法绕