前言

在每个公司的系统中，总有一些拥有复杂业务逻辑的系统，这些系统承载着核心业务逻辑，几乎每个需求都和这些核心业务有关，这些核心业务业务逻辑冗长，涉及内部逻辑运算，缓存操作，持久化操作，外部资源调取，内部其他系统RPC调用等等。时间一长，项目几经易手，维护的成本得就会越来越高。各种硬代码判断，分支条件越来越多。代码的抽象，复用率也越来越低，各个模块之间的耦合度很高。一小段逻辑的变动，会影响到其他模块，需要进行完整回归测试来验证。如要灵活改变业务流程的顺序，则要进行代码大改动进行抽象，重新写方法。实时热变更业务流程，几乎很难实现。

LiteFlow框架的作用

LiteFlow就是为解耦复杂逻辑而生，如果你要对复杂业务逻辑进行新写或者重构，用LiteFlow最合适不过。它是一个轻量，快速的组件式流程引擎框架，组件编排，帮助解耦业务代码，让每一个业务片段都是一个组件，并支持热加载规则配置，实现即时修改。

使用LiteFlow，你需要去把复杂的业务逻辑按代码片段拆分成一个个小组件，并定义一个规则流程配置。这样，所有的组件，就能按照你的规则配置去进行复杂的流转。

LiteFlow的设计原则

LiteFlow是基于工作台模式进行设计的，何谓工作台模式？

n个工人按照一定顺序围着一张工作台，按顺序各自生产零件，生产的零件最终能组装成一个机器，每个工人只需要完成自己手中零件的生产，而无需知道其他工人生产的内容。每一个工人生产所需要的资源都从工作台上拿取，如果工作台上有生产所必须的资源，则就进行生产，若是没有，就等到有这个资源。每个工人所做好的零件，也都放在工作台上。

这个模式有几个好处：

• 每个工人无需和其他工人进行沟通。工人只需要关心自己的工作内容和工作台上的资源。这样就做到了每个工人之间的解耦和无差异性。
• 即便是工人之间调换位置，工人的工作内容和关心的资源没有任何变化。这样就保证了每个工人的稳定性。
• 如果是指派某个工人去其他的工作台，工人的工作内容和需要的资源依旧没有任何变化，这样就做到了工人的可复用性。
• 因为每个工人不需要和其他工人沟通，所以可以在生产任务进行时进行实时工位更改：替换，插入，撤掉一些工人，这样生产任务也能实时的被更改。这样就保证了整个生产任务的灵活性。

这个模式映射到LiteFlow框架里，工人就是组件，工人坐的顺序就是流程配置，工作台就是上下文，资源就是参数，最终组装的这个机器就是这个业务。正因为有这些特性，所以LiteFlow能做到统一解耦的组件和灵活的装配。

LiteFlow不适用于哪些场景

LiteFlow自开源来，经常有一些小伙伴来问我，如何做角色任务之间的流转，类似于审批流，A审批完应该是B审批，然后再流转到C角色。

提示

这里申明下，LiteFlow只做基于逻辑的流转，而不做基于角色任务的流转。如果你想做基于角色任务的流转，推荐使用flowable (opens new window)，activiti (opens new window)这2个框架。

LiteFlow适用于哪些场景

LiteFlow适用于拥有复杂逻辑的业务，比如说价格引擎，下单流程等，这些业务往往都拥有很多步骤，这些步骤完全可以按照业务粒度拆分成一个个独立的组件，进行装配复用变更。使用LiteFlow，你会得到一个灵活度高，扩展性很强的系统。因为组件之间相互独立，也也可以避免改一处而动全身的这样的风险。

LiteFlow相比于Flowable和Activiti

Flowable和Activiti都是极为优秀的流程引擎框架，其中Flowable的底层也是Activiti，他们除了能做基于任务角色的流程，也能做基于逻辑的流程，并且他们的基于BPM协议，很多基于BPM协议的编辑工具都能为他们可视化编辑流程。

LiteFlow和他们相比，虽然功能不如他们那么多，但是胜在轻量，高性能和极少学习成本上。而且这2款都是国外开源，集成起来比较重，而且文档本地化做的也不够好。LiteFlow拥有完善的本地化文档和使用范例。在大部分的场景可以帮助你改善你的系统。