Saas.元数据驱动开发（原理，抽象，实现方面整体讲解）

前言

读者要求

本文面向具有一定开发经验的开发，并且需要对开发中的一些共同点能有所总结

Saas类阅读前可以去体验体验 Salesforce，销售易CRM，纷享销客CRM系统等系统

为啥要用元数据驱动

企业信息建模的核心是面向对象，面向对象（Object-Oriented）将客观世界看作由对象组成的，对象由属性和操作组成，对象可按其属性进行分类，对象之间的联系通过传递消息来实现。

元数据是支撑企业信息数字化建模的地基，元数据（metadata）是描述对象的数据，对对象的属性、操作及联系的描述性信息。

元数据驱动是一种设计模式，也是一种开发模式，是用简单架构去构建复杂业务的灵魂。元数据驱动的分层建模体系是建立在元数据基础上对实体进行业务分层，上层业务是构建在底层业务实体基础上的，这样无论咋样复杂的业务都可以解决。

Saas为啥要用元数据

如果是工具类Saas服务，或者扩展能力稍微弱一点的Saas服务，都没必要上元数据，DB都有自己的元数据管理体系，使用起来很容易。

但如果是扩展性要求较高，或者需要构建PaaS平台的Saas服务，就需要自己来管理元数据，这样能集成较多自己的功能。

Saas为什么要用元数据驱动开发

管理元数据： 是一种解决可变性字段/扩展字段的一种解决方案

元数据驱动开发：是一种开发模式

把元数据自己管理，完全从可以技术上解决。但为什么开发要按照元数据驱动呢？ 想想自己日常的开发，尤其是ORM，CRM，ERP等传统软件开发页面，大部分是不是列表，详情，添加/编辑，导入导出，跳转到关联的多方列表， 审批流程，跟外界交互(消息，Email等)，操作A影响B 等类似操作，如果只是项目性(单个租户)的系统，直接去DB建表实现即可，但如果要兼容多租户特性化需求就需要，从问题的本质更抽象上一层，抽象软件里边的操作。如： 创建的每张表，可以为一个实体，实体有很多字段，有一些规则和约束来保证数据完整性，对这个实体需要CRUD操作，操作实体可能触发一些操作，或者要修改一个状态需要一个审批流程。实体和实体之间有联系，可以通过订单查看购买商品的列表，也可以在订单页面添加商品和编辑商品。订单到了一定状态，可能需要生成一条开发票的信息等等。这样的逻辑是不是在开发过程中经常遇到，但Saas就是基于这一层来开发，所以使用元数据驱动，相当于基于实体，实体关系，实体相互影响这样的面向对象的方式来组织业务，这就是基于元数据驱动的开发模式。

相关联的架构模式，如果基于DDD领域驱动的架构模式，其实是从架构，需求沟通，代码组织等方面来落地基于面向对象的开发模式方法论。

操作抽象

元数据驱动结构

元数据驱动开发过程

实体：(静态)

1. 字段属性：名称，key，可见性，是否常用，类型，是否必填，系统字段(只可以代码中获取到，不可编辑)

2. 完整性：字段长度，数据范围，校验规则

3. 唯一性：主键ID，业务联合主键(查重规则)，唯一性字段，自动编号

4. 索引：根据业务字段创建索引

5. 关联关系：设置关联的实体，字段(默认按照ID管理，展示的是字段)

实体：(动态)

1. 新增，详情，编辑…… 等操作，预留前端或者后端代码位置，可以控制展示特征(如：顺序，可见性，顺序，可编辑)

2. 打印模板定义(如需要)

3. 操作前后的自定义逻辑，预留给实施人员，集成人员，二次开发人员

4. 单项流程(名字我自己起的)：由实体的某个属性触发，单向异步 (触发后就不管了)

5. 中断流程(名字我自己起的，其实就是审批流)： 某个实体的某个属性变更需要 流程进行后才可以生效，否则就不能变更

6. 状态/阶段：这两个是对实体一些具有生命周期的字段的单独体现，用的比较多，比如订单的状态变更

7. 流程，状态便跟前后增加自定义逻辑

实体互动

操作 - 事件 - 操作

1. 变动监控：

A： 变动属性值的时候，同步调用外部业务逻辑并触发流程

B：变动属性输出日志；异步监控日志，生成事件，进而触发事件中的操作

2. 影响：

A：生成M条B或者C数据

B：修改B的属性值

C：跟外界交互

注意点

1. 架构上需要考虑：paas平台，开发态，实施集成。区别：PaaS平台是专门平台的开发组，切记建立同开发，实施的沟通机制，防止平台组自说自话。 开发小组：可以写代码，架构不好的开发和平台代码在一块，导致开发学习成本，沟通成本极高； 架构的时候预留的接口需要考虑开发的实际开发的流程，代码管理，可实现的功能等方面内容，否则业务开发小组在驱动不了架构平台组的时候只能自己找代码修改。 

2. 考虑大批量操作对底层的影响，以及及时业务操作的实时性业务需求。大批量数据操作bulk接口，必须为异步，包括内部对：实体操作前后，可能触发的流程或者事件，如果是同步的话， 必然会对系统有较大的压力，从而影响正常的业务流程。可全部为异步操作，只进行数据的完整性校验，然后记录日志，保证这部分业务的事务原子特性，其他的操作根据操作日志来异步分析和同步

3. 统一接口很重要：API标准，文档必须完善； 条件允许需要暴露查询语言。 一定要屏蔽元数据服务底层逻辑，否则上层应用开发将异常艰难，这些标准需要适当的培训和沉淀。 并且平台需要提供一定的工具，类似Mysql的Navicat一样可以方便查询，用来查询问题

4. 预留给开发态需要考虑小组分工，尽可能从代码层面做到解耦。而且不同业务小组的代码也可能解耦，否则就是灾难性的。

附录：

Force.com的数据定义和存储参考：

Force.com的多租户架构理解（一）

Force.com的多租户架构理解（二）

Force.com的多租户架构理解（三）

Force.com的多租户架构理解（四）

Force.com的多租户架构理解（五）