低代码设计教程（四）-元模型设计（元模型如何构建）
我们知道大部分低代码平台都采用了模型驱动的开发模式，即通过可视化建模的方式来实现软件的设计和生成。领域模型创建完成后，有两种技术路线来生成和运行模型应用：
- 方法一：对生成的模型进行编译并生成所有相关的源代码，使其成为普通的应用系统，该技术称为“代码生成”；
- 方法二：利用模型解析执行引擎直接解析并运行所生成的模型，该技术称为“模型解析”。
什么是模型驱动开发呢？其实这种架构设计在大型2B的企业项目中是比较常见的：
基于元数据建模思路
所谓软件系统设计，核心是对现实的对象进行数字化，如果采用一对一映射建表的“硬建模”，业务对象间的关系分散在各个存储表中，业务对象的新增和变化都会对数据表造成影响，业务对象关系的新增和变化都会对数据表的Schema造成影响。
这里有一张在电信机房的配线架图片，我们分别用“硬建模”和“大类元数据建模”思路来分析两种建模方式的差别。
电信机房配线架
“硬建模”方案，我们设计了一个配线架管理的物理模型表（蓝色部分），随着硬件工艺升级，我们的配线架升级为双面配线架，这个时候我们需要增加一个新的模型：操作面（黄色部分）。我们发现这次需求升级，模型改动涉及面很大，增加了三个关系，和操作面相关的模型都需要进行调整，影响了四个模型实体。
硬建模方案
这次改动带来的生产影响是什么呢？
- 数据库层面新增1个表、改动3个表
- 应用层面新增1个对象、改动3个对象，新增3个操作函数
- 必须要停止数据库来进行改动操作
采用“硬建模”设计的架构简单可读，项目维护简单，但是一旦需求升级变化，30%的代码都需要进行调整，那么相关的测试、实施投入都相对较大。
“大类元数据建模”方案，我们定义了一个“硬件”大类模型，硬件具备包含、容纳关系能力。针对双面配线架需求，我们的改动仅仅是在元数据中增加了一个“操作面”的定义，如果“操作面”的的属性没超过“硬件”属性范围，我们都不需要增加物理表。如果操作面有特殊属性，我们只需要在物理库增加一张扩展表，而业务关系和核心属性都在主表“硬件”上进行管理，相关的业务代码也无需调整，系统也无需停机。
基于大类元数据建模
我们归纳下大类元数据建模思路如下：
- 保持大类业务实体和关系实体的稳定，关系全部体现在大类上；
- 细类继承大类业务实体和关系实体，以扩展表方式实现灵活扩展；
- 通过元数据配置驱动，实现模型快速、在线扩展；
大类元数据建模思路
这里我们讲解的大类元数据模型是一种软件架构设计方法，也是低代码软件架构设计方法：既稳定又易用
平衡的架构设计
稳定性
越抽象越稳定。E-R是所有MIS数据模型的起源，可以描述世界上任何东西，最稳定。但越抽象，则意味着越多的工作丢需要应用来完成，且不易为程序员和用户理解。
易用性
越贴近现实越容易使用。对现实实体一对一的“硬建模”最容易理解和使用。但建模越“硬”，则意味着停机改动数据模型的可能性越大，越容易对生产造成负面影响。
实用性
实用性取决于应用需要什么抽象度的管理对象。包括：管理对象的粒度——实体（E）和管理对象的功能——关系（R），我们架构设计的过程需要从E-R出发，细分实体和关系概念，直到满足各应用的管理要求为止。
