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

一、背景

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

二、spring statemachine是干啥用的

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

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

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

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

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

三、spring statemachine的好处

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

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

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

    好了，废话时间结束，下一章，咱们正式开始第一个例子，运行一个demo，请你们期待，由于这个例子真的没啥用：）