今天准备再写一篇关于低代码开发平台的文章，在前面讲云原生整体解决方案的时候，我谈到过低代码开发平台，但是对里面的一些核心组件以及组件间的集成没有展开描述，而这些刚好是一个低代码开发平台设计和实现的关键内容。
低代码平台概述
对于低代码开发平台，百度词条有一个基础定义，如下：
低代码开发平台（LCDP）是无需编码（0代码）或通过少量代码就可以快速生成应用程序的开发平台。通过可视化进行应用程序开发的方法（参考可视编程语言），使具有不同经验水平的开发人员可以通过图形化的用户界面，使用拖拽组件和模型驱动的逻辑来创建网页和移动应用程序。低代码开发平台在完成业务逻辑、功能构建后，即可一键交付应用并进行更新。
如果再对这个定义里面的关键内容做下提取，其核心包括：
- 无须编码或少量编码
- 可视化和可配置化，通过组装或配置构建应用
在这两点之外，还有一个关于过程支撑层面的，即整个开发完成的应用上线或交付过程应该足够简单和自动化，包括上面提到的可以实现配置立即生效，实现一键交付等。
当前有很多提供低代码开发平台的服务商，各家的方案或整体架构虽然有差异，但是本质的内容基本还是一致，即一切皆是可配置，可建模的。
可以设想下开发一个简单功能的过程，基本也就是数据库表设计，前端界面设计，编写逻辑层代码和接口实现业务规则，挂接流程引擎实现流程，配置功能和数据权限等。
所以任何一个低代码开发平台都需要围绕这个核心去抽象和建模，找出共性的和业务无关的东西进行技术沉淀，即我们常说的。
完全标准的东西直接标准化
非标准但是同样场景的东西，通过抽象差异来实现参数化配置
大家可以看到，实际我们LCDP平台的构建基本就是围绕上面思路展开。那么一个LCDP平台的核心要素究竟是啥，具体我重新画了一张图来说明。
即LCDP平台的核心包括了上图中的数据建模，表单建模，流程建模，权限建模，报表建模和规则建模几个关键部分的内容，通过这些建模组件，包括这些组件之间本身的协同来完成一个完整业务系统和功能的构建。
对象建模驱动
一个好的低代码开发平台应该是以对象建模为驱动的，这个有点类似于很早以前谈到的MDA模型驱动架构的思想。即首先进行对象建模，这里的对象更偏业务对象或领域对象，一个对象本身可以对应到多张数据库表，可以是层次结构表，也可以是管理结构表。
对象建模完成，朝前可以暴露领域服务能力接口，朝后可以对接数据库进行持久化。当暴露领域服务能力接口的时候更加容易实现前端和后端逻辑之间的彻底分离和解耦，同时在领域服务实现内部也更容易进行相关的事务控制。
在采用对象建模后，实际在后端模型和前端界面之间增加了一个对象服务层，对象服务通过API接口方式对外提供，这个和SOA分层应用构建思路是吻合的。
在对象建模完成后，对象本身朝下可以生成数据库表，朝上可以发布API接口服务。而对于表单建模不再直接和数据库表关联，而是直接引用对应的API接口服务，在这种情况下对应API接口服务本身也会启用强服务契约模式进行定义和设计。
当有了独立的接口层的时候，可以看到要实现上层功能组合或组装将变得更加容易和方便，即我们可以提供一个类似传统BPEL流程或服务编排的工具，可视化来进行上层业务的接口组装和编排。
表单和流程引擎集成
当前市面上很多低代码平台本身即是从传统的BPM软件或工作流引擎平台演变而来的，因此流程引擎本身是低代码平台底层很重要的一个技术服务能力支持。
对于流程引擎本身和组织模型绑定紧密，以进行相应的细粒度数据权限控制和流程动态权限控制，在这里先不描述具体的组织引擎和流程引擎集成点，而重点分析表单和流程引擎的集成。
表单设计挂接流程
可以先看下最简单的一个场景，即表单设计和流程设计本身即分离的，可以提前先设计好流程模板，产生一个流程模板ID，然后开始进行表单设计。表单设计完成后，可以选择一个流程模板ID进行挂接。
在这种场景下表单在提交的时候启动流程本身也简单，即：
- //GenerateFormID();
- //Form.Save();
- //StartWorkflow(Formid，WorkflowTemplateID，Userid）;
流程审核人填写扩展信息
如果挂接的流程，所有流程节点的处理人都是简单的审核通过不通过，填写要给处理意见，那么上面的处理方式完全满足。但是更多情况下审核时候需要填写扩展信息。
比如一个供应商创建申请单，流转到采购经理处审核的时候，采购经理需要确定供应商的等级，并上传供应商相关资质信息。供应商等级和供应商资质两个数据项本身是属于供应商对象建模的基础数据项信息，但是不在单据提交的时候维护，而是在审核时维护。
在这种场景下可以看到不能简单的在表单和流程模板之间建立简单的关联和映射，而是应该在表单数据项和流程节点之间进行映射。单独数据项进行映射粒度太细，因此可以在表单设计的时候引入数据分组，处理数据分组和流程活动节点之间的映射即可。
如上图，对表单数据进行分组，并建立流程活动节点和表单分组之间的映射和授权关系。整体的表单提交和审批流程就变化为：
- 申请人提交表单信息，只能看到基本信息
- 审批1进入审批，可以看到扩展分组，并对数据维护再提交审批结果
- 审批2进入可以看到三个分组信息，但是只能对扩展分组2进行数据维护，并审核提交结果
- 流程监控中，对于已经执行到的节点，扩展分组信息可见
即以上既实现基于流程的参与人动态权限控制，同时又实现了流程参与人可以在审核流程的过程中对流程表单信息进行维护和填写。扩展分组信息在维护后仍然保持在基础的对象数据表，而非流程实例表中，流程实例表仅仅只负责状态流转和下一个阶段流程参与人计算等。
动态权限+数据权限控制
动态权限简单来说就是你在处理流程节点过程中有权限查看表单数据，但是处理完成后你的权限即回收。或者说你仅仅能够看你审核和处理的表单，而不是所有的供应商表单数据。而数据权限则是确认你具体可以看到整个数据对象的哪些数据项，比如前面的分组授权也是常用的控制数据权限的方式。
表单保存和流程启动流转解耦
当流程引擎独立作为技术服务实现的时候，可以看到对于流程启动，流程流转等都是调用的API接口服务来完成，那么这个时候就形成了分布式事务场景。
比较好的做法仍然是表单存储和流程API服务之间需要异步解耦，即对流程流转触发请求先写入到消息中间件，然后在异步订阅消息队列数据来启动流程或流转节点。
流程规则实现
在整个流程的处理中，还涉及到规则的处理和实现，而对于规则可以理解为两种。
其一是简单的判断规则，比如报销单金额超过1万需要流转到总经理审核；还有一种是负责规则判断，比如需要进行详细预算完整性检查，通过和不通过需要流转到不同分支。
结合传统流程引擎实现方式，对于简单规则可以走参数变量传递，而对于复杂规则，则可以考虑直接调用外部API接口服务来实现校验。
在这里只传递需要用作流程判断的数据项目信息参数到流程执行中，本身也减少资源负荷。对于Param信息的传递，一个思路是在流程实例启动后进行缓存，一个是在每一个流程活动节点执行的时候都重新传入。个人建议方式是在流程实例启动的时候进行缓存。
表单和组织权限模型集成
在前面已经谈到对象建模要和表单建模分离，即一个对象建模完成后，实际基于这个对象可以构建多个不同的表单模型，还是拿供应商举例。
一个供应商即使不挂接流程也可以拆分为供应商完整信息维护，供应商银行信息维护，供应商模糊查询，供应商资质信息查询，特定供应商信息查询等不同的表单功能，但是这些表单功能都对应同一个对象模型。表单设计完成后形成的是表单功能。一个表单设计完成后，可以挂接到具体的功能菜单上，同时也可以和某个具体的操作按钮或事件绑定。简单来说就是表单本身可能是存在入口参数的。
一个供应商查询功能表单，查询结果是列表，可以点列表里面的详细信息链接，这个时候应该调整到特定供应商查看界面，那么供应商ID就是重要的传入参数。
可以看到整体权限控制思路仍然是基于角色+资源的访问授权。
一个表单挂接到菜单资源，菜单可以授权给用户组或角色。同样，对应表单设计中的数据项或数据分组也可以定义为需要细粒度控制的资源对象，在资源定义完成后讲资源对象授权到具体的用户组或角色，包括表单中的按钮等都可以采用该思路进行。
即在表单建模完成后，我们需要对建模完成的表单抽象资源对象，资源对象可以是一个独立的数据项，也可以是数据分组或者按钮操作。同时再将资源对象和角色或用户进行绑定。
数据项权限默认设置
一个数据项权限配置最好是既支持默认可见，也支持默认不可见。比如采购订单金额只对采购总结可见，那么这个数据项目默认值则是全不可见，同时将金额定义为资源，授权给采购总监角色。
静态权限和动态权限重叠
当静态权限和动态权限重叠时候如何处理？一般来说应该是以动态权限为主，比如静态权限设置是没有权限，但是动态权限计算后可操作或可维护，那么该用户在动态流程执行中对相关信息就具备动态权限控制。流程处理完后权限即消失。
表单和规则引擎
对于低代码开发平台来讲，实际上我个人并不建议引入比较重的规则引擎，要明白如果真的业务规则很复杂，用规则引擎同样需要写大量的脚本代码才能够实现，而且这个脚本代码本身后续更加难以维护。
规则引擎出来这么多年，实际现在很少看到很成熟的在企业信息化领域的应用场景。
对于规则，我们可以分开来看。
一种是基于当前前端已有的表单数据就能够进行计算和校验的规则，这类规则一般为参考完整性规则，比如当我在电商平台订购商品的时候，选择了10件商品，都有不同的折扣，但是有些折扣不能同时共享，那么这个时候前端就能够完成规则计算给出一个最佳折扣和总费用。对于这类规则，表单设计器是需要支持的，最好方式是能够脚本化，可以自己写简单的规则定义脚本并进行处理。
还有一类规则为需要调用后端数据才能够完成计算的规则。比如在提交报账单据申请的时候，需要在后台校验当前预算是否足够和满足，满足的才能够提交。
第二类规则实际才是规则引擎可能涉及的场景。
即在第二类场景下整体流程可以理解为
- 在规则模型中定义规则，规则接受输入并产生输出
- 表单传入关键param参数到规则引擎
- 规则引起基于param参数从数据库后台获取数据
- 基于提前定义的规则进行规则计算
- 返回规则计算结果给表单前端
f如果规则复杂你会看到规则是不能通过简单的配置就实现的，仍然需要写大量的规则脚本代码。那么在这种情况下更推荐的方式是自己来实现自定义的API接口。
表单设计过程中，对于关键事件点都可以调用自定义API接口。
当前快速开发平台叫低代码开发是合适的一个叫法，即不要期望所有复杂地方都能够配置出来，特别是复杂规则实现。最好的方式就是复杂规则仍然是自己写代码实现接口，然后在表单建模和流程建模的时候能够调用自己写好的API接口方法。
事件是一个软件开发里面标准概念，点击按钮，下拉选择框，焦点移出等都可以触发事件。对于事件触发后在无规则的情况下就会调用表单自己的处理逻辑。
比如保存按钮，事件触发后就调用表单保存操作对数据进行保存。但是实际上你会看到在保存前你可能需要进行业务规则和逻辑处理，在保存后你可能触发其它关联操作。
- //Form.SaveBefore();
- //Form.Save
- //Form.SaveAfter();
当前在保存前你还可能调用多个API接口进行多个校验。
这个时候就出现另外一个关键点，即不仅仅是支持事件前后调用外部API接口，还需要支持对API接口进行简单的编排。
实际上你可以看到，对于一个完整的低代码开发平台，面对各种复杂业务场景的时候，这种开放的编排能力是必须的。这种编排思路实际和SOA上的服务组合或流程编排思路是一致的。
服务组合编排
还是以电商产品购买为例，在进行订单提交的时候，如果需要同时处理三个动作。即调用订单对象的保存操作，调用库存对象的库存扣减，调用配送单对象的配送单自动创建。
在这种场景下你可以看到如果没有服务组合和编排能力是很难实现的。
即将对象建模暴露的接口能力进一步进行可视化的组装和编排，形成组合服务能力再暴露给表单设计中使用。
一个好的低代码开发平台参考SOA分层架构思想和领域建模思想是必要的，即对象建模设计完成后暴露API接口服务能力，前台的表单设计是和API接口服务层进行交互。这种设计方式方便后续进行服务能力编排的扩展。
即使前期没有可视化服务编排能，我们也可以自定义API接口服务能力进行接入。
