当业务规模比较小、系统复杂度不高时，运维、测试、数据分析、管理等支撑功能主要由各系统或者团队独立完成。

低代码系统建设的核心是快速构建不同的行业应用，如果各个行业应用都采取各自为政的方式来实现这些支撑功能，会发现重复工作非常多。

所以在建立低代码平台的核心能力包括两方面：

• 平台能力（稳态）：抽象可复用的能力和模型，如用户体系、协同能力、知识库能力，各个应用围绕这个平台能力做好应用扩展。
• 应用扩展适应能力（敏态）：基于收敛的平台能力，根据各行业在数据管理模型、业务流程多变的特点，搭建一套动态模型扩展，动态流程扩展的应用开发平台。

今天我们主要来讲解低代码如何设计平台能力。

多产品、多租户能力

在第一章文章中，我们描述了老板的需求，他希望公司有多个低代码产品，“xx文档”，“xxBI”，“xx协同”，同时，这几个产品要具备统一的企业权限管理能力（收费能力）。

我们把需求用例细化下：

企业注册场景

1. 个人注册
2. 填写企业信息，创建企业
3. 当前企业管理员默认为当前创建人
4. 员工邀请同事加入企业（短信、邮件、链接）
5. 受邀人根据链接，并验证手机号码并加入企业（无账号自动注册）

员工切换企业场景

1. 员工登录默认使用上次登录的企业信息，无则使用第一个企业信息；
2. 获取当前账号在当前企业可以使用的产品及功能权限；
3. 员工通过个人信息切换企业；
4. 功能菜单刷新，重新获取当前账号在当前企业可以使用的产品及功能权限；

基础实体关系

通过以上用例，我们可以总结出如上实体关系：

• 一个平台有很多个企业（租户）；
• 一个平台也有很多用户；
• 一个用户属于多个企业（租户），一个企业（租户）也有很多个用户。

这个是基础的关系。所以实际上一般 SaaS 平台会有三个后台：

1. 运营管理后台：即平台运营管理的后台系统，通常用于管理租户，主要是租户的权限、资源的分配管理；这个平台我们作为 SaaS 用户是接触不到的，但是作为 SaaS 产品设计是必不可少的。
2. 租户管理后台：即租户使用的管理后台，主要是用于租户的管理员管理成员和分配租户内部成员的权限、资源。
3. 业务产品应用：也就是实际租户的各个成员使用的业务系统，我们以钉钉举例，比如我们平时使用的钉钉的桌面端、App 其实都算是业务应用。这个业务应用其实是有多个的。比如钉钉自带的 OA 审批、考勤系统、智能填表等等，其实都是一个个业务应用。有些设计为了简化，在后台系统上，会将租户管理后台和业务应用合并为一个后台。

租户权限管理设计

对于一个平台，租户是其服务的主要对象，也是最终的买单人，即 SaaS 系统的订阅者。因此，SaaS 的运营管理后台的一个核心职能就是管理平台上的租户的权限和资源管理。

平台会有若干个产品应用，租户首先选择开通平台中的某些应用。当然，应用内可以再细分出销售版本。

应用租户关系

菜单管理

菜单是产品中最核心的资源，菜单的创建模式包括两类：

• 产品功能菜单，如BI产品的视图配置功能，数据集管理功能，都属于产品功能菜单，这些功能是可以纳入产品的销售能力范围；
• 用户菜单，如一篇文章，一个表单，这部分菜单所有权属于产品应用本身，由菜单所有者分配共享权限，例如我们在企业微信创建的一个表格，可以共享给哪些同事共享编辑或者企业的某个部门同事只读访问；

讲完这里，我们可以看到我们的实体模型关系如下：

• 一个平台会有多个产品；
• 一个产品会有多个菜单，通过菜单组合成多种销售版本；
• 一个产品下，用户会创建多个用户菜单（表单、文章），菜单可以打包成多个权限组（只读，维护，列权限）
• 用户菜单权限组可以分配给多个用户；
• 企业属于1个平台，企业可以根据自身需要订阅多个平台下的产品的某个销售版本。
• 企业拥有多个用户，用户也可以属于多个企业，但用户则属于同一个平台。

平台核心资源模型

角色管理

为了方便的管菜单资源的人员分配，我们引入了角色，把多个用户纳入一个角色，方便分配菜单权限。

这里需要注意的是，产品包括了两类菜单，两类菜单的管理方式就分成两个场景：

1. 在租户管理后台中，企业管理员需要根据业务管理需要，分配不同的管理角色来管理不同的产品能力。
2. 在业务产品应用，内容发布者可以选择企业通讯录中的角色或者员工进行内容授权。

针对以上场景，我们的角色模型如下：

• 一个企业的通讯录下有多个业务角色；
• 一个业务角色包括多个员工；
• 用户菜单可以分配个多个业务角色，业务角色可以绑定多个用户菜单；
• 一个企业可以有多个产品管理角色；
• 产品管理员角色可以管理当前企业被授权的产品功能域内的产品功能；

角色模型

多租户数据隔离

目前SAAS的租户数据隔离方案包括以下三种方案：

1. 独立数据库系统：成本高，支持租户数量少，隔离级别最高，安全性最好，能够满足不同租户的独特需求，出现故障时恢复数据比较容易恢复；
2. 共享数据库，独立表空间：成本中，支持租户数量较多，提供了一定程度的逻辑数据隔离，一个数据库系统可支持多个租户，出现故障的情况下，数据恢复相对而言比较复杂；
3. 按租户id字段区分：成本低，支持租户数量较多，维护和购置成本最低，每个数据库能够支持的租户数量最多，隔离级别最低，安全性也最低，数据备份和恢复非常复杂，需要逐表逐条备份和还原；

在低代码平台中，相对以上模型，我们对产品做了衍生：

• 产品：由平台或供应商提供能力；
• 应用：由企业通过产品提供的能力自主创建，例如企业根据我们的BI平台创建了两个应用，“财务运营分析”和“项目管理分析”，员工可以分别进入不同的应用进行自己的菜单构建设计。

由于产品的生命周期由平台或供应商管理，所以我们每个产品的数据源都采用独立数据库系统建立，原则上不同产品在数据共享上无数据库级别依赖需求，应用依赖通过接口调用实现；

应用属于企业通过零代码构建，所以应用的数据源我们默认会共享平台数据库，按应用ID建立不同的表空间，当然也提供高级配置，可以多个应用共享一个表空间。

在我们的部分非低代码SAAS产品中，一般采用方案三较多，当然会根据客户等级进行调整。

产品应用分库方案

平台能力

前面我们讲了平台的模型及平台管理能力，即平台运营管理的后台系统，通常用于管理租户，主要是租户的权限、资源的分配管理，这部分属于核心运营支撑能力；

核心运营支撑能力

企业通讯录管理

同时，我们为了更好的运营低代码平台，需要提供一部分辅助支撑能力，如：统一认证、消息系统、帮助中心、素材库、API能力管理。

统一认证登录

文档中心

素材库

API&测试用例

从技术架构设计上，为了规范各产品之间的协同和统一，降低集成复杂度，提升用户体验，在企业、产品、资源、用户模型上，我们可以扩展消息模型、工单模型、SNS模型，需要根据产品的演进路线逐步进行归纳统一。没有完美的架构，只有不断演进的架构。