低代码平台设计方案

目标

在线的低代码开发平台，用户在平台界面经过托拉拽就能完成开发完，线上直接就能使用，不须要学习任何计算机知识，无需关心后端前端数据库等，只需考虑页面托拉拽设计，表单设计，流程设计，数据建模等，就能完成一个应用

核心领域划分

领域:是指根据必定的规则将业务问题限定在特定的边界内，从而划分为一个个范围

根据云枢、氚云等平台使用文档中能够理解到，LowCode平台的使用流程抽象出来即以下所示

表单设计——>数据建模——>流程设计——>视图设计

完成之后，用户根据设计好的流程使用，填写数据，提交表单，在视图(后台)看到相关数据

由此得出四个领域

1. 表单域
2. 数据模型域
3. 工做流域
4. 视图域

除了工做流域相对独立，剩下三个域都有必定关系

表单和视图须要使用数据模型，数据模型是由表单建立，视图和表单是列表和详情的关系

各个域的做用和分析

表单域

用户在客户端界面经过托拉拽页面的组件自定义布局来设计本身的表单，此表单就是指一个html的提交表单

表单由组件构成，1对N的关系，表单实体有表单属性和配置，每一个组件有本身的属性和配置。

后端不该该关心表单和组件，只负责考虑用合适的设计去存储表单和组件的属性、配置，为前端提供支持，前端须要考虑如何去运用这些数据。

这么设计的好处在于，先后基本彻底分离，后端只负责存，前端怎么用怎么改由前端本身作主，符合单一职责和开闭原则

表单的构建同时也是初始化数据模型，数据模型是由组件的字段构成的一个数据结构，这部分后端要完成三个目标，

• 数据模型的初始化
• 配置的自动装配
• 配置的生效使用

这是LowCode的核心基础之一，决定了LowCode平台的能用与否，关于数据模型在下文详细分析。

综上所述，表单域的需求:

• 前端和后端须要共同定义一种"通用格式"，它的做用有两个，前端如何能根据这个"通用格式"能方便快速的渲染页面包括布局和组件，后端如何根据这个"通用格式"获取数据模型的字段，举个例子，最省事的作法就是将整个页面的HTML代码保存，前端请求获取HTML，并渲染。
• 数据模型
• 表单可随意定制，随意更改，保存，发布

数据模型域

表单在完成的时候就会同时初始化完成数据模型，数据模型的字段是来自表单的组件，数据类型就是表单的组件属性。

数据模型是贯穿整个LowCode平台使用的对象，全部的操做和配置包括但不限于CURD都是做用于数据模型，因为表单能够任意更改组件，因此致使数据模型的成员也是会任意变更。

初始化完成的数据模型，应该内置五种方法:新增，更新，删除，查询，列表查询，也可绑定自定义方法集成服务。

数据模型还容许绑定规则，即触发事件。例如当对数据模型进行新增的时候，知足A条件的状况下，触发A+事件。(参考云枢和氚云后，氚云是不暴露数据模型也就没有这一个域，而云枢暴露，关于这一点我的认为优先级不高，不属于核心，而属于迭代功能)

数据模型能够内置权限，指定角色能够查看哪些数据，同上理由，这也不属于核心，优先级不高。

数据模型真正的核心点是就是有一套"框架"能高度抽象化模型从而能屏蔽模型差别作到高层次调用，目的只有一个：

内部造成一种机制，以零代码的方式配置，让 Web 请求能处理 Action

举个例子，假设有这种"框架",不管个人数据模型结构如何，一旦建立，就能自动生成对应的curd方法并能够直接使用，最普通的案例就是代码生成器。然而这只是最基本的，若是再加上上述的规则，权限，配置等，就将是很复杂的实现。

综上所述，数据模型的需求:

• 搞个框架?
• 数据模型的初始化
• 内置五种基本方法，并能对数据模型进行操做
• 规则，权限，配置的自动装配生效使用

视图域

视图其实就是一个后台管理列表页面。能够理解为表单是一个client，视图是一个后台系统，提交的表单数据都能在视图上看到

视图跟表单不同，视图的限制比较大，视图仅仅就是个列表页，在给定的页面结构和配置，让用户抉择使用

用户能够在视图页，指定展现哪些字段，字段是数据模型的子集。数据模型内置的五种方法在视图的提现就是五个按钮，查询按钮能够用户配置查询条件，可随时更改。

总结下来，视图的主要属性是配置，这一块的重点跟表单同样，主要是前端如何将视图的布局配置传给后端，传一大段html代码。后端只要数据模型那一块"框架"搭建的好，这里就能够作到以零代码的方式配置，让 Web 请求能处理 Action，点击相应的按钮就能自动处理。

综上所述,视图模型的需求

• 前端和后端视图页面的数据流转
• 内置方法的装配使用

工做流域

工做流域相比其余域，是独立存在的，它所在层级应该是最外层覆盖的范围也是四个域里最大，用户执行的操做都是在工做流里的流程。

工做流指“业务过程的部分或总体在计算机应用环境下的自动化”。是对工做流程及其各操做步骤之间业务规则的抽象、归纳描述。

举个例子，最多见的请假流程，员工A发起请假———>主管B审查经过——>老板C赞成。这就是一条既定的工做流，是一个既定的"规则"

综上所述，工做流域的需求

• 后端调研选型一个合适的工做流引擎，投入使用
• 前端将工做流引擎提供的web UI 设计器进行二次开发，符合需求的样式(工做流的web组件UI太丑

聚合

根据对上述域的分析，能够总结出来每一个域对应的聚合和实体，如图所示

红色标识表示聚合根，白色表示实体，根据这些聚合咱们就能在实际的代码里，分好四个模块，这也是DDD的优点

聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每个聚合对应一个仓储，实现数据的持久化。

聚合有一个聚合根和上下文边界，这个边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象

若是把聚合比做组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不只是实体，仍是聚合的管理者。

对领域的分析已经肯定了上下文边界并整理出四个聚合，其中工做流自己就独立，能够不算聚合。相关的功能介绍，在领域分析已通过了

1. 数据模型聚合(核心): 聚合根是模型字段。
2. 表单聚合：聚合根是控件。
3. 视图聚合：聚合根是配置。

实现思路

开头先说答案:

以mongoDB为主用来操做数据的CURD，mysql为辅支持组件配置，仿SpringMVC，servlet实现完成LowCode流程的初始化，配合工做流完成程序的运行

分析提到，表单是可随意更改组件布局，这就致使了数据模型里的字段也是会随意变更，而数据模型又是整个程序流程中最重要的一环，那不管是出于实现难度、可拓展性、方便性考虑，关系型数据库如mysql都显的过重。

广泛方案都是采用一个表单一个表，存放数据字段，这里就是涉及到选择哪一种数据库，不妨简单思考一下代码逻辑实现，

• 当用户完成表设计之后，代码须要根据这个表单，建立一个表，用户更改表单如添加、删除组件，代码须要操做数据库对表添加、删除字段；

• 数据模型是要使用的，因为表单的不肯定性，致使表结构的不肯定性，要求保证能正确的对每一个不一样的表单完成curd,从这又延申出2种解决方法：

  1. 每次更新表单时，根据表结构动态生成class类从而实例化依赖orm对该类进行curd操做。
  2. 不依赖orm，字段匹配去进行curd操做
• 数据模型的字段还跟其余配置如规则，权限等捆绑，若是随意更改，那这些也要想办法相应的更改

不解决上述3点，LowCode就迈不出第一步，更不用谈"框架"。

问题就是如何方便的、拓展性高的、逻辑清晰的解决上述问题

利弊分析

针对上述问题，关系型数据库和非关系数据库的优劣分析

• 为不一样的表单建立不一样的表，每一个表有不一样的字段而且还会随时更改，针对这一点，很明显的关系型数据库弊大于利，若是有N个表单就有N个表，若是这时多表修改表结构会拖垮数据库。
• 数据模型的curd，因为模型的多变性就须要考虑不一样的结构的抽象性，关系型的数据库有两种方式：1.动态生成class类 2.依赖SQL用字段匹配。非关系型数据库：字段匹配直接进行curd就行。
• 与模型相关的配置，这部分变更不频繁相对有固定的结构，从实现来讲关系型的数据库会更合适。

使用MongoDB来操做数据

关于mongo的介绍这里不赘述
经过下图能够快速了解mongo的一些概念

MongoDB 有一个很是突出的特色，即文档的概念，文档是一个键值(key-value)对(即BSON)。MongoDB 的文档不须要设置相同的字段，而且相同的字段不须要相同的数据类型，这与关系型数据库有很大的区别

一个简单的文档例子以下：

{"site":"www.baidu.com", "name":"百度"}

集合就是 MongoDB 文档组，集合没有固定的结构，这意味着你在对集合能够插入不一样格式和类型的数据，好比，咱们能够将如下不一样数据结构的文档插入到集合中：

{"site":"www.baidu.com"} {"site":"www.google.com","name":"Google"} {"site":"www.zhihu.com","name":"知乎","num":5}

这个特性就很是的符合上述表单更改组件致使数据模型结构变动，能很好的包容表单多变的特性，能很好解决表单变更频繁，
不妨假设一下，若是咱们有请假表单、审批表单等结构不一样的表单，对应的数据模型也不同，可是mongodb很好的包容了这分差别，这是mongo查询的用法

db.drivers.find({name: "Xiaose"}) #查找 name 为 Xiaose 的文档
db.drivers.find({age:{$gt:20}}) #查找 age 大于 20 的文档

得益于mongodb结构，咱们不须要关心具体的字段是什么就能作到将curd抽象，只须要符合作好字符匹配，实现难度低，扩展度高。

同理，对于表单自己这种变更频繁的，也可也

低代码框架时序图

通过上面分析，数据模型的curd已经没什么大问题了，剩下的就是在代码设计层面，如何像spring或者springmvc那样的框架，作到配置自动装配，配置自动生效，诸如事件机制，触发器，监听器等，如何组合并运用这些通过合理设计作到自动化，达到低代码或零代码的目的。

水平不够，往后待定

代码设计

根据领域和聚合的分析，按照DDD设计，代码结构如图，关于DDD分层概念这里不赘述。

• application : 应用层，负责编排领域服务
• domain：领域层，领域对象，仓储，领域服务
• infrastructure：基础层，提供项目的基础工具、组件使用
• interfaces：用户接口层，面向前端的一层

各层流程图

总结

低代码平台是一个大型的工程，不是一蹴而就，其最核心的地方仍是后端如何处理一系列配置从而实现低代码的目的

核心业务以下：

1. 后端如何作到低代码开发配置(自动解析数据模型，自动装配CURD方法，使用规则等)，这是低代码平台的基础
2. 前端和后端的数据交互格式，后端如何告诉前端 界面的设计，前端能展示出来，这是低代码的门户
3. 数据如何落地