摘要：让我们先看下状态机的概念。下面是状态机模型中的个要素，即现态条件动作次态。因为订单和审批公文都有很多的流程，每个流程都会产生状态的变化，而且流程是这种业务的主轴，其他都是围绕这个流程和状态变化来考虑的，所以看起来蛮适合用状态机来做。
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，请大家期待，因为这个例子真的没啥用：）
源代码地址
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/74948.html
摘要：在实际的企业开发中，不可能所有情况都是从头到尾的按状态流程来，会有很多意外，比如历史数据，故障重启后的遗留流程，所以这种可以任意调节状态的才是我们需要的状态机。 1、伪持久化和中间段的状态机我们设想一个业务场景，就比如订单吧，我们一般的设计都会把订单状态存到订单表里面，其他的业务信息也都有表保存，而状态机的主要作用其实是规范整个订单业务流程的状态和事件，所以状态机要不要保存真的不重要，...
摘要：先来一个，它的主要作用就告诉状态机的初始状态应该啥样，然后把整个状态流程都用代码配置出来。继承了类，表明身份，我就是来配置状态机的初始状态，并描绘一下状态流程的全过程。 上一篇说了很多废话，这一篇就不唠叨，先跑起来 1、来个spring boot去start.spring.io新建一个springboot的项目，虽然我对spirngboot也有不少的牢骚，但作为demo的开始，还是一个...
摘要：目前为止，我们都是从状态流程的开始阶段创建一个状态机，然后一路走下去。然后就可以愉快的在里面看怎么用了发送事件持久化恢复状态机后的状态为执行完保存后，大家可以自己在客户端查看以下，是不是有内容保存进去了。 目前为止，我们都是从状态流程的开始阶段创建一个状态机，然后一路走下去。但在实际业务中，状态机可能需要在某个环节停留，等待其他业务的触发，然后再继续下面的流程。比如订单，可能在支付环节...
摘要：创建了后，状态机就可以不只是传一个，可以组合和数据内容一起发送给状态机变化的处理类了。到这里为止，状态机通过对象就和其他的业务代码做到了数据连接。 在企业开发中，数据在不同的业务间传输是最常见的工作，所以虽然我们的主架构是用的状态机，也就是从流程状态的角度来看待这个项目，但在具体业务中，每个状态的转变中会牵涉到各类业务，这些业务有些需要收到状态机变化的通知，需要把状态值传递给业务类和业...
摘要：讲讲复杂流程的需求除了上面文章里面提到的一根筋状态机流程，实际的企业应用中状态机的流程会更加复杂，而我们最常用到的就是。当然，里面还有很多其他的东西，大部分是处理复杂状态机流程的，以后有机会我们再展开讲。 1、讲讲复杂流程的需求除了上面文章里面提到的一根筋状态机流程，实际的企业应用中状态机的流程会更加复杂，而我们最常用到的就是choice。它类似于java的if语句，作为条件判断的分支...
阅读 2374·2021-10-19 11:45
阅读 2083·2021-09-30 09:56
阅读 1237·2021-09-30 09:47
阅读 490·2019-08-30 15:53
阅读 1724·2019-08-30 15:44
阅读 409·2019-08-30 12:52
阅读 987·2019-08-30 11:16
阅读 1467·2019-08-29 16:36
