低代码设计教程(四)-元模型设计(元模型如何构建)

我们知道大部分低代码平台都采用了模型驱动的开发模式,即通过可视化建模的方式来实现软件的设计和生成。领域模型创建完成后,有两种技术路线来生成和运行模型应用:

  • 方法一:对生成的模型进行编译并生成所有相关的源代码,使其成为普通的应用系统,该技术称为“代码生成”;
  • 方法二:利用模型解析执行引擎直接解析并运行所生成的模型,该技术称为“模型解析”。

什么是模型驱动开发呢?其实这种架构设计在大型2B的企业项目中是比较常见的:

低代码设计教程(四)-元模型设计(元模型如何构建)

基于元数据建模思路

所谓软件系统设计,核心是对现实的对象进行数字化,如果采用一对一映射建表的“硬建模”,业务对象间的关系分散在各个存储表中,业务对象的新增和变化都会对数据表造成影响,业务对象关系的新增和变化都会对数据表的Schema造成影响。

这里有一张在电信机房的配线架图片,我们分别用“硬建模”和“大类元数据建模”思路来分析两种建模方式的差别。

低代码设计教程(四)-元模型设计(元模型如何构建)

电信机房配线架

“硬建模”方案,我们设计了一个配线架管理的物理模型表(蓝色部分),随着硬件工艺升级,我们的配线架升级为双面配线架,这个时候我们需要增加一个新的模型:操作面(黄色部分)。我们发现这次需求升级,模型改动涉及面很大,增加了三个关系,和操作面相关的模型都需要进行调整,影响了四个模型实体。

低代码设计教程(四)-元模型设计(元模型如何构建)

硬建模方案

这次改动带来的生产影响是什么呢?

  1. 数据库层面新增1个表、改动3个表
  2. 应用层面新增1个对象、改动3个对象,新增3个操作函数
  3. 必须要停止数据库来进行改动操作

采用“硬建模”设计的架构简单可读,项目维护简单,但是一旦需求升级变化,30%的代码都需要进行调整,那么相关的测试、实施投入都相对较大。


“大类元数据建模”方案,我们定义了一个“硬件”大类模型,硬件具备包含、容纳关系能力。针对双面配线架需求,我们的改动仅仅是在元数据中增加了一个“操作面”的定义,如果“操作面”的的属性没超过“硬件”属性范围,我们都不需要增加物理表。如果操作面有特殊属性,我们只需要在物理库增加一张扩展表,而业务关系和核心属性都在主表“硬件”上进行管理,相关的业务代码也无需调整,系统也无需停机。

低代码设计教程(四)-元模型设计(元模型如何构建)

基于大类元数据建模

我们归纳下大类元数据建模思路如下:

  1. 保持大类业务实体和关系实体的稳定,关系全部体现在大类上;
  2. 细类继承大类业务实体和关系实体,以扩展表方式实现灵活扩展;
  3. 通过元数据配置驱动,实现模型快速、在线扩展;

低代码设计教程(四)-元模型设计(元模型如何构建)

大类元数据建模思路

这里我们讲解的大类元数据模型是一种软件架构设计方法,也是低代码软件架构设计方法:既稳定又易用

低代码设计教程(四)-元模型设计(元模型如何构建)

平衡的架构设计

稳定性


越抽象越稳定。E-R是所有MIS数据模型的起源,可以描述世界上任何东西,最稳定。但越抽象,则意味着越多的工作丢需要应用来完成,且不易为程序员和用户理解。

易用性


越贴近现实越容易使用。对现实实体一对一的“硬建模”最容易理解和使用。但建模越“硬”,则意味着停机改动数据模型的可能性越大,越容易对生产造成负面影响。

实用性


实用性取决于应用需要什么抽象度的管理对象。包括:管理对象的粒度——实体(E)和管理对象的功能——关系(R),我们架构设计的过程需要从E-R出发,细分实体和关系概念,直到满足各应用的管理要求为止。

相关新闻

联系我们
联系我们
公众号
公众号
在线咨询
分享本页
返回顶部