开发一个系统,最关键的部分不是系统的界面,也不是和数据库之间的信息交换,而是如何根据业务逻辑开发出符合实际需要的程序逻辑并确保其稳定性、易维护性(模块化和结构化)和弹性(容易根据实际业务逻辑的变化作出程序上的变动,例如决策权的改变、组织结构的变动和由于业务方向的变化产生的全新业务逻辑等等)。 Workflow 引擎解决的就是这个问题:如果应用程序缺乏强大的逻辑层,势必变得容易出错。
就好比一辆汽车,外表做得再漂亮,如果发动机有问题就只是一个摆设。应用系统的弹性就好比引擎转速方面的性能,加速到 100 公里需要 1 个小时(业务流程发生变动需要进行半年的程序修改)还能叫好车吗?引擎动不动就熄火(程序因为逻辑的问题陷入死循环)的车还敢开吗?(来源于百度百科)
为了解释这个问题,我们来举个例子:
应用场景: 张三工程师正在研发一套 OA、ERP 等企业信息管理平台
客户需求: 有个物资系统,客户希望这么做,A 填写申请表 ——B 部门经理审核 ——C 物资管理部确认 ——D 张三领用物资
张三工程师: 立刻开始了业务需求调研,分析,总结。然后开始写代码了。业务表单很简单(这里我们就忽略了)
审批设计:-1 退回修改 0 保存编辑 1 部门经理审核 2 物资部门确认 is_use 是否领用
根据设计:写了如下代码:
public function check(){
$code = input('code');
$userId = session('uid');
switch ($code){
case 1: //B核准
//一大堆逻辑代码
break;
case 2: //c物资部核准`
//一大堆逻辑代码
break;
default: //张三发起申请
//一大堆逻辑代码
}
}
}
这时候,张三工程师,很快写完了代码。逻辑也正确,权限判断完全没问题,很高兴的跟客户开始了一系列的骚操作,并审核通过。
时间过了半个月,软件还在运维应用期间。客户给张三工程师打电话,我们领导说,要增加一个审核功能,
改为:A 填写申请表 ——B 部门经理审核 ——E 主任核实 ——C 物资管理部确认 ——D 张三领用物资
问题来了: 而这个客户系统,有数十条,类似的审核业务?如果都这样变动?
这时候,求张三工程师的心里阴影面积?
总结下: 从上面的例子来说,不能说张三工程师的代码逻辑有问题,业务逻辑有问题。但是问题在哪里?
我个人认为,在于没有很好处理业务与逻辑之间的关键因素。我们常说,信息管理系统业务是一半,工作流程是一半。如何整合好这两个关系。需要应用到工作流引擎。
李四接手了,张三的业务,全面分析了,下系统。决定开发个专门管理该公司的业务流程问题。 把业务与流程剥离。
通过可视化快速构建。在 2 分钟就完成了上面的逻辑架构,同样的,改造了数十条业务逻辑。而这些,他只用了不到 1 个小时。
通过上面的小 Demo 应该很容易看出工作流强大的优势在于哪里。
不管你业务怎么变化,流程怎么变化,都能通过可视化的拖拽设计,
把专业的流程驱动交给专业的流程引擎,归集与统一。
你省去的不仅仅是流程的调研,客户需求分析时间,
更是你写 if else 一大堆重复代码的时间。
最后回到原题:
深入浅出,工作流引擎。LCDP(低代码开发平台)的出现并非偶然,而是在发展过程中的必然,专业化的表单设计,流程驱动,会打破传统开发的弊端,为企业在快速构建,数据驱动上提供先进的技术生产力!