在介绍本项目之前,我先想与大家谈论谈论业务框架 和 技术框架的问题 以及工作流的诸多问题

我想这些话是更比这个项目的源码更有用的

那是很早的事了.. 回忆在这几年JavaEE的路途中,我的老师在讲Struts2框架(那还是SSH的时代)的时候 提过一段概念,这让我记忆犹新 什么是软件?什么是框架?

软件(也即给公司做的各种系统) = 应用组件(不变的) + 业务组件(变化的)

应用组件来形成框架，即框架是半成品的软件！

先定义一个概念 框架分为 技术框架 和 业务框架

列举几个Java领域的框架 SpringBoot Spring MyBatis SpringMVC Hibernate 此种框架大家可以理解为 纯技术框架 从gitHub上下载下来 它与我们即将要做的任何系统里面的业务逻辑是没有任何关系的 同时他们也只能算系统分层开发中的某一层, 比如MyBatis 仅仅是持久层(Manager,Dao) SpringMVC(Action,Controller)

但大家需要明白的是 工作流框架(JBPM,Activiti,Flowable,Camunda,Zeebe) 并不仅仅是 技术框架, 它从另一个角度来说 也可以算做是 业务框架 为什么这么说呢? 因为工作流确确实实解决了某些审批中的疑难问题 以及 业务编排的中的诸多问题 在审批流领域: 工作流框架提供了整个流程图运转的核心代码,对比于传统的状态机来说,她就灵活多了

另外 也直接就解决了工作流系统中的一些常见业务的代码实现 比如: 流程跳转与驳回,撤回,审批转办,委派,审批过程中加签,减签,流程迁移,我的待办,我的已办,我发起的,等等常见痛点需求 而且工作流并不是系统分层开发中的某一层,它本身就连接了几十张表 他是一个完整的项目 解决了审批领域/业务编排系统的痛点

像我们来做业务系统来说 一般情况下 二次开发框架的可能性是非常小的 比如像Spring 我们顶多自己定义一些 BeanFactory FactoryBean 一些Processor 比如像MyBatis 我们顶多自己定义一些 Plugin Interceptor 但是这些东西并没有改动人家本来的源码 只是我们多加了一些东西

但像工作流框架就不一样了, 以Activiti 567 举例 其框架就没有实现中国式的动态审批跳转以及驳回(注意:不是通过流程图画连线来跳转驳回 我指的是没有连线也能跳转 想跳哪跳哪) 可以想象一下 我们自己实现流程跳转和驳回那是相当困难的,需要熟悉Activiti底层使用的一些类 诸如ExecutionEntity TaskEntity CommandContext XXXAgenda 等等

以上我想表达的意思就是

• 工作流框架 算是技术框架 + 业务框架
• 二次开发工作流框架是相当有技术难点的

这才造成了 各大视频讲解各种Spring MyBatis源码的视频 多如繁星 而深度讲解工作流的视频国内都没几个(主要是相当有技术难点,而且因为工作流和业务会产生关系)

第二 中国式流程 基本上 属于中国内地才有这样的需求,在外国就没有了,比如流程跳转,驳回, 所以在Activiti ,JBPM时代 这是更加痛苦的 以往别的框架有问题 我们可以去StackOverFlow里面搜 ,在工作流框架里面 这个法子就不灵了

第三 你像 工作流框架本身就要操作 几十张表, 他内部的逻辑 对我们来说 算是黑盒 但是别的系统我们自己写的业务代码 都是白盒(因为是我们亲手写的) 一旦工作流内部有问题,我们得各种阅读其本身源码, 这是是工作流框架复杂的另一个原因