如何设计流程和节点操作之间的协调弹性

1.生活中的节点和操作的实例

由于在我们的业务系统中，很多操作都是面向流程和操作节点的，简单的说就是要完成一个事情，它分为若干个要点，若干个要点又有若个步骤。下面以我们做米饭的流程进行说明：

做米饭的流程

做米饭的主节点流程

做米饭前的要点
做米饭中的要点
做米饭后的要点

做米饭的后续的步骤则是做米饭的具体操作过程。

2.生活中节点和操作的演变

也即做米饭这件事上，它分为三个要点，若干个步骤。这个是最原始的版本。但是这个版本不是唯一的，因为相对它而言，还有电饭锅，这个时候，做饭的步骤可能会会进行精简，但是它的主流程和相关的若干步骤是不会随着它而进行改变。它离不开：

做米饭的流程改变

3.考虑样中的扩展性和伸缩性

但是在使用电饭锅的时候，在做饭的过程中，你可能水放多了，此时你的需求改变了，此时电饭锅需要有一个容错性，还是会根据你的要求将去做成饭，但是也可能会将其做成粥，此时就看设计电饭锅的人了，或者这个需求对电饭锅的设计初衷了。此时设计电饭锅的人会在上面标上一个水位线，告诉你这个是做饭的，高水位线是做粥的。但是也有人会对水位线视而不见。此时如果电饭锅会进行容错，将其做成粥，或者还是做成饭，但是此时的饭水比较多，就取决于客户的意见或者产品的定位了。

也即在做选择时，我们会考虑在电饭锅的设计上，会给用户多一点选择，同时这种选择是可能允许使用电饭锅犯错的，但是按照电饭锅的运作进行的。

扩展的流程，在原有基础上衍生出来的，比如在做饭的饭做完后，我需要保温，此时可以提供保温功能。同时在做饭或者煮粥的过程中，我想它具有定时功能，能在特定的时间煮饭或者煮粥。

因此这个流程和操作节点是可以组合使用或者可以在此基础上进行扩展时，所带来的处理问题的过程中流程和节点是可扩展或者说是弹性的。

4.业务流程中的要点

在实际业务中，我的业务系统中，经常会对原有的业务进行业务流程的增加或者对其进行减少。此时需要做的事设计好流程和操作节点之间的。操作流程属于流程节点，一个操作节点有多个操作流程。

在医院中，因为我们看病的过程是流程式的，首先需要预约挂号，当有了号之后，才能进行下一步操作，看诊，然后进行后续流程，医生开处方，捡药。这个过程具有有序性。

因此设计这个流程时，我们需要考虑流程的顺序性，必须给其设置一个属性顺序和流程编码。为了保证节点的灵活性，我们可以在原有的基础上增加节点和减少节点，只要不影响主要节点的流程。因此，它也必然有一个开关属性，同时为了防止流程的错乱性，或者流程的完整性，必然还需要一个属性是否只读。流程节点中包含多个操作。此时的操作流程是具体的，里面必然包含操作的名称和编码。

有了流程和节点，也即此时我们就具备了类似于netty一样的事件了。有了事件，此时对应的自然少不了对应的业务。因为业务必须要依赖流程和操作节点，而节点和流程类似于一个人的骨架，而具体业务就是人里面的各个器官，它们都有自己的功能，它们共同组合起来形成有机的整体，协调作业。

那么流程之间又是怎样联系的呢？采用传递的方式，根据code来进行传递。当一个流程完成或者一个操作完成，此时会进行对应code的改变，此时可以配合前端实现。

5.业务之外框架

在业务之外，框架也有类似的流程操作。比如netty中就是基于事件执行对应的业务操作。比如spring中的上下文ApplicationContext的概念都是这样的一个概念。还有为什么讲流程，因为流程可以更清楚的了解事物进行到了哪一步。基于流程编排式的操作，还有比如saga模式使用流程编排也是类似的思想。或者我们在基于下单过程中，加入中间变量或者状态机来解决下单中遇到的状态和一致性的问题。以及进行链路追踪的ThreadLocal线程副本，都有这样类似的概念。当然这只是个人的理解。