spring statemachine的企业可用级开发指南1-说些废话

1、背景
在我打算学习spring statemachine的时候，我几乎看过了所有网上的中文教程，基本上都处于浅尝辄止的阶段，有几篇讲的比较深入的，都只是堆代码，具体用在什么地方，都语焉不详，我打算把我一路摸索的过程记录下来，方便大家能继续前行。

2、spring statemachine是干啥用的
spirng statemachine是干啥用的，这个其实是个问题来的，但很多的教程的问题也在这，一上来就是告诉你有这么个玩意，然后就是开始怎么安装，怎么运行，功能有哪些，特性列起来，但就不告诉你这个东西能干啥，所以我打算在把spring statemachine跑起来之前，先说下spring statemachin能干啥。让我们先看下状态机的概念。

有限状态机（英语：finite-state machine，缩写：FSM），简称状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。应用FSM模型可以帮助对象生命周期的状态的顺序以及导致状态变化的事件进行管理。将状态和事件控制从不同的业务Service方法的if else中抽离出来。FSM的应用范围很广，对于有复杂状态流，扩展性要求比较高的场景都可以使用该模型。下面是状态机模型中的4个要素，即现态、条件、动作、次态。

现态：是指当前所处的状态。
条件：又称为“事件”。当一个条件被满足，将会触发一个动作，或者执行一次状态的迁移。
动作：条件满足后执行的动作。动作执行完毕后，可以迁移到新的状态，也可以仍旧保持原状态。动作不是必需的，当条件满足后，也可以不执行任何动作，直接迁移到新状态。
次态：条件满足后要迁往的新状态。“次态”是相对于“现态”而言的，“次态”一旦被激活，就转变成新的“现态”了。

这是状态机的定义，这个我不打算多说，因为概念性的东西，诸位请自行搜索，那么在实际应用中，状态机会应用在什么地方呢？不知道大家怎么想，我在接触到状态机的时候，第一时间想到的就是订单和审批公文，这是我在工作中实际遇到的场景，所以我学习spring statemachine的主要动力也是为了能处理这两种情况。因为订单和审批公文都有很多的流程，每个流程都会产生状态的变化，而且流程是这种业务的主轴，其他都是围绕这个流程和状态变化来考虑的，所以看起来蛮适合用状态机来做。

那是不是一定要用状态机来做呢，这可不一定，因为在没有状态机之前的订单流程大家也能实现，这世界缺了谁都正常运转，所以状态机不是必须的，在可以用状态机解决这种流程和状态变化的场景下，为什么要用，这是另外一个问题，因为可以用和决定用之间，还有个问题，那就是用这个有啥好处呢？

3、spring statemachine的好处
在做软件项目的时候，我们会以各种各样的角度看一个项目，比如OOP，万物皆对象，一个订单就是一个对象，所谓的状态变化，无非就是订单这个对象的变量在不停的变化，变化的过程就是对象的方法；再比如数据库，万物无非CRUD的组合，订单不过就是增删改查，数据库原子操作的组合罢了。这些角度对吗？可以说都对，因为用这些角度都有人做出了项目，但有些角度对项目的理解会比较方便，有些角度就比较费劲，比如订单，如果是订单的生成查看，用CRUD就是很适合，因为这个角度很契合；如果是订单和商品的关系，订单和其他业务的关联，OOP的角度就很适合，因为用封装、多态的视角比较容易看清楚这类业务和他们之间的边界，方便划分各自的功能。而状态机的角度，就是以状态变化和流程运转为角度切入看问题，所以对于流程性为主轴的项目就很适合，所以是不是用spring statemachine，衡量的标准就是，这个项目的主轴，或者场景是不是一个流程性、状态变化为主的项目，如果是，就可以考虑用spring statemachine了。

这个问题其实还没回答完，上面说的其实是在什么情况下用spring statemachine，但还没回答好处在哪里。要回答这个问题，要从软件项目的一些特质说起。上面说了，软件项目其实有很多的办法完成，手段很多，完成的情况也各有优劣，那怎么判断用什么办法好呢，我觉得答案就是看项目主要解决的问题是什么。软件项目既不是程序员练手的工具，也不是老板用来蒙钱的门面，它是用来解决问题的，所以能清晰的表达问题，解决问题的手段就是好的技术手段，所以，如果一种技术手段很清晰的表达了软件项目的问题和解决方法，那么这就是这个技术最大的好处，而状态机对于流程性、状态变化的场景，它就是一个清晰的表达方式，这就是它的好处。

这样说可能有些朋友会不以为然，一个技术框架的好处难道不是功能强大，使用方便，性能卓越这些东西吗。我的理解是上面说的这几点都很重要，但都是次一级的问题，能清晰的表达问题和解决问题的，才是核心的好处。在《人月神话》的《没有银弹》这篇文章里面就提到过软件特性的根本困难和次要困难，而对问题的表达和解决其实就是对需求的准确描述和实现，这就是软件开发的根本困难，所以能够清晰表达这个的技术框架，就是解决根本困难的好工具，项目技术选型最重要的好处考量。至于功能、性能这些，都是次要问题，虽然spirng statemachine在次要问题上也并没有什么缺陷。

好了，废话时间结束，下一章，我们正式开始第一个例子，运行一个demo，请大家期待，因为这个例子真的没啥用：）

源代码地址