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