前言本篇博客的重点将放在“流程讲解”和“Activiti7的一些关键功能”上。详细的Activiti7教程我会在后面的一篇博客中详细讲解。主要是我自己还没学完。需求都写好了，所以功能执行的流程要按照甲方爸爸定义的流程来写。那么我们就可以理解进程的概念了。了解了流程的概念之后，我们需要了解我们一般是如何执行流程的呢？一般的流程，我们自己设计流程表，然后把我们的流程表和我们的业务数据绑定起来，让我们的流程一步步进行。我们通过一个请假的流程来描述一下一般我们是如何实现这个功能的：可能一开始我们看到上面的流程会觉得这个很好，一目了然，耳目一新。说实话，我也是第一次有这种感觉，不太好。但告诉你，这一切都是幻觉。在上面的设计过程中，我们不仅要管理我们的业务数据，还要管理我们的任务数据，而且各个任务数据之间可能存在一定的关系。我们也一定要留着，不然怎么确定主管在审核谁的请假申请！！！！！！所以这显然会增加我们在数据管理上的压力。这种设计方法不能说是错误的，但是任何时候随着现代时代的发展，必然会出现这样的情况：“部门越来越细化（就是他妈的很多部门），流程越来越多复杂，而且处理时间越来越长……”在这种情况下，如果我们还是自己设计表，然后和我们的业务数据进行绑定，那么显然“不仅开发难度会增加很多，而且后期维护的难度也会增加很多”。所以我们还是要使用流程框架来帮助我们开发更高效的流程。变更需求-->逼程序员去死说完流程的大致概念，我们来看看为什么需要流程框架来帮助我们简化流程的开发。原因无外乎这么几点，“一是开发越来越难，流程越来越复杂，二是需求一天到晚变。”想想在没有使用流程框架之前，你写一个流程是多么的辛苦。客户说流程变了，你是什么心态？顺便跟大家说说需求变更后最让我们头疼的具体地方。相信开发过程中最烦的就是需求一直在变。因为需求一旦发生变化，就会引起下面一系列的反应。如下图所示：因为会上面有一系列的连锁反应，所以后端开发人员一般是在需求尽可能详细后才开始开发。因为一旦需求发生变化，下面的几项基本上都需要更改。数据库重构大家应该都能看懂。不懂就算了，举个下面的栗子。每个人都会明白。假设我们设计了一个关于用户User的表如下：但是现在客户有一个新的需求，我们需要存储用户的详细信息包括：电话号码，家庭住址，教育背景等，那么显然我们数据库中的User表需要重建。而重构会有以下两种情况：1．“直接在原表中添加字段。”2.“新建一张表，在表中添加字段，然后将两张表关联起来”。可能这时候会有人说，第一个解不就好了，不是第二个解鲨鱼！！创建另一个表来关联它真的很有趣！！其实不是我杀掉的，这个其实要看情况，明明我们在上面的示例User表中，可以直接给表添加字段，但是下面的User表呢？假设我们的表中已经有30个或更多的字段，那我们还可以继续添加字段吗？很显然，这样做是愚蠢的，相当愚蠢，非常愚蠢，绝对绝对的愚蠢。因为“一张表的字段太多”会严重影响我们对数据库“各种操作的性能”。所以只能选择先分表再关联的操作。这样我们就可以相对的保持我们数据库相关操作的性能。流程需要重写。其实这一点大家都能理解。举个例子帮助大家理解：假设我们曾经开发过一个请假的功能。假设我们之前的请假流程是这样的：但是需求改成了这样：那么很显然，我们整个关于请假流程的写流程都会随之改变。所以我们的后端开发最烦人的就是需求又变了，这让我们整个开发过程变得异常缓慢，甚至有时候“重构的过程比拆掉重新做的还要长”。所以我们看到“程序员和产品经理打架的新闻”很正常。如果新的模块之间的耦合关系只有上面那一种就好了。我怕客户会提到一个以前没有提到过的模块。如果这个模块只和我们的第一个模块或者最后一个模块相关，其实也可以。恐怕他说的功能模块卡在两个模块的中间，这是致命的。不仅要和前面的模块一样需要绑定，同时还需要绑定后面的模块。这是一个两难选择。这就像某种艺术的表演操作，看网剧的时候好不容易等你过了开头的广告，后来好不容易看了半集电视剧，他就给你插广告了。看完广告再看下半集电视剧，你说你不生气。图片Activiti7还是比较方便快捷的。它谈到了很多关于流程和流程开发的复杂事情。下面简单介绍一下Activiti7是如何帮助我们实现的！这里简单介绍一下，详细的教程会在下一篇博客完整分享。首先，“关于流程的表不需要我们单独设计和创建，Activiti7会自动为我们创建和管理。”想想看，这是多么美妙的事情，基本上流程的所有问题都可以交给Activiti7来完成。第二点Activiti7大大简化了我们之前重复的管理任务信息和相关操作。我们首先要了解Activiti7的进程运行。我们可以通过下图来理解：在Activiti7中，一开始就部署了操作的整个流程，这样每个用户的操作都会遵循这个流程。然后让我们通过这个订单。我们先画一个BPMN文件。可以看到我们在BPMN文件中定义了整个流程的操作，将流程中的操作细分为对应的“任务节点---（发起请假，批准请假）”，用户每完成一个动作，相应的任务节点完成并交付给下一个任务节点。当所有任务节点完成后，流程结束。这样我们就不用考虑如何存储任务节点及其关联信息，所有这些操作都交给Activiti7来操作。之后我们只需要部署流程定义：@AutowiredprivateRepositoryServicerepositoryService;//根据bpmn部署流程@TestpublicvoidinitDeploymentBPMN(){Stringfilename="BPMN/Part4_Task.bpmn";//BPMN文件所在位置Deploymentdeployment=repositoryService。createDeployment().addClasspathResource(filename).name("流程定义部署测试").deploy();System.out.println(deployment.getName()+",部署成功");}这样我们的流程定义就部署成功了。然后我们需要初始化一个流程定义的流程实例：@AutowiredprivateRuntimeServiceruntimeService;//初始化流程实例@TestpublicvoidinitProcessInstance(){ProcessInstanceprocessInstance=runtimeService.startProcessInstanceByKey("myProcess_Task");//BPMN文件的Id名称System.out.println("ID:"+processInstance.getId());System.out.println("ProcessInstanceId:"+processInstance.getProcessInstanceId());System.out.println("ProcessDefinitionId:"+processInstance.getProcessDefinitionId());}这样，我们的流程实例就创建好了。之后，我们就可以一步步执行我们流程实例中的任务节点了。@AutowiredprivateTaskServicetaskService;//执行任务@TestpublicvoidcompleteTask(){taskService.complete("2d22f941-3f67-11eb-b3b6-3c58c24c1a1b");//任务节点ID号System.out.println("任务节点有beenprocessed");}这样我们就可以完成我们的任务节点了，所有的任务节点都完成之后我们的流程也就完成了。是不是很方便快捷？而即使甲方爸爸修改了需求，我们只需要重新绘制我们的BPMN文件，然后重新部署，就可以将我们对应的完成任务节点的操作与我们的业务数据对应起来。这是相当快的。它不需要和以前一样。下面是一个简单的写号请假流程，是不是很方便快捷！！！！本文转载自微信可以通过以下二维码关注“萌萌哒的璐璐”。转载本文请联系萌萌的公众号。
