背景
最近做发票的开具和冲销业务，其中有N多状态。于是想到了状态机模式，减少条件判断，让业务逻辑更清晰。回头增加或者减少状态，自己也能快速建立全局视图。理想很丰满，现实很骨感。
技术选型之路
作为Java开发，首先想到的是Spring家族的状态机，毕竟Spring够强大。一顿操作运行起来之后，发现得先整理自己的基本预期和诉求，如下:
- 业务对象本身有个状态字段，状态机每次基于该字段做初始化;
- 业务对象所能接收的事件，其字段内容应该可轻松扩展;
- 状态转换过程中的事务与业务上下文强一致;
对应到Spring State Machi,后面简称SSM。
- 初始化。SSM是基于全局状态机。何为全局状态机，即状态机初始化之后，状态保持所有节点和边的对应的对象，服务于后续具体的状态转换。官方文档也提到属于重量级对象，建议全局唯一。也正式这个原因，在使用过程中存在并发问题，使用不当可能导致死锁。状态转换完成后，需要实现特定的持久化接口完成状态机的状态保存。
- 事件。事件是基于枚举的和注解的，这条是最狠的。枚举的内容，不能修改。也就意味着事件只有类型这么一个可变参数。
- 至于状态迁移暴露出的各种事件接口，只能说强大到许多都用不上。
- 事务边界难以控制，因为内部实现有看不见的异步任务。
小结下SSM，有点儿类似于一个状态机引擎，偏重量级，事件对象表示不够丰富，事务控制个人水平原因吧不敢保证。
工期原因就自己开发，参考Java的状态模式，定义StateContext和State。每个State只关注当前状态，支持的事件，以及对应事件的业务逻辑。操作步骤如下
- 先来一发状态图说清楚状态和转换事件，个人用VSCode中的markdown插件完成；
- 再来一个状态业务表，说明状态A，收到事件时执行的业务；
- YY运行一遍，就完成了设计；
- 优化一波，各个状态中执行的业务差别在参数不同，提一个状态抽象父类作为状态模板。每个状态增加如下方法，是否支持某个事件，该状态支持的所有事件。
业务整合
到这里，状态机的壳子就完成了，发现另外一个问题。什么业务放在状态Service中，什么业务放在普通Service中，两者的关系是什么。显然，状态业务应该放在状态Service。个人认为，状态业务在普通Service之下，应该嵌套其中，因为对外不关心你是怎么实现的。如果mapper是0层，Service是1层，那状态服务就是0.5层。这个问题解决之后，事务控制也就好办了。
测试中的发现
- 使用状态机以后，测试的内容分为状态本身和具体业务，也就是模板类中的方法。测试状态机就像测试纷繁复杂的If分支，不过状态机的分支可轻易穷尽，If分支我是没有信心的。如果愿意把所有的状态转换日志收集起来，还可以可视化出整个状态转换过程。
反思与小结
- 设计模式还是很强大的，需要掌握的不是细节，而是整体的脉络。需要的时候，细节再研究。
- 也许SSM只是希望输入一个状态和事件得到一个结果状态，是我在用法上有问题。毕竟在状态中执行业务逻辑也是有耦合的。理想的应该是通过事件监听的方式松耦合，这是从SSM中学习到的。
