低代码平台代码导出设计

前言

在低代码平台中，如果需要支持复杂模型多数情况下会要求具备模块级别的源码导出功能，独立模块可以导出为独立运行的原生代码方便与业系统进一步集成。在低代码平台相对成熟的今天，这一功能也成为了绝大多数商业企业级低代码平台的必备功能，本文将从模块代码导出的角度来聊一下，低代码平台的代码出码设计。

一，低代码平台常用出码模式

在用户完成基础的视图设计以及应用逻辑编排后，通常需要将业务设计通过特定的方式转化为可执行的代码及配置以便于仿真测试或者直接交付部署应用。通常这个过程有以下几种方式：

（1）模板模式(直接出码为可执行原生代码)

早在低代码相关技术诞生以前，代码生成模式就风靡于架构设计圈子。由架构师确立技术路线和代码结构，通过framake等模板语言将数据库或者通用配置批量的生成基础代码，然后交由程序员进行二次加工。

这种方式优点是：

简单易操作，一个稍有经验的高级程序员即可完成整套的基础模板设计，在经过模板输出后可以大幅降低普通程序员的劳动强度。

但缺点也很明显：

首先由于模型设计过程中过于简单，缺少元数据以及元元数据属性的支撑，在代码生成时需要更高级的属性支持时只能在模板中去丰富，这就造成代码模板会被严重污染大幅降低通用性，在真实使用过程中往往会出现一个项目一套模板，甚至一个程序员都有一套自有模板的囧局。这使得项目可维护性大幅降低，另外代码在生成后，多数情况下还需要进行一些二次补充和修改。这个些过程中通常是不可逆的，这使得代码生成只能在项目初始构建的时候使用，对于功能扩展或者代码重构都无法发挥其应有的作用。

小结：

单纯的代码生成模式如果纯粹作为程序员或者微型项目组，作为代码工具使用尚可，在早期低代码平台中也比较常见于各种行业模板等应用，但随着技术进步，这种方式正在逐步被淘汰。

（2）引擎驱动模式（出码为DSL）

引擎驱动模式最早来起源于“中间件”设计，其设计目的是将大量具有通用意义的业务逻辑进行抽象包装，提供独立的数据模型业务驱动模式再根据业务特性，抽象出特定的DSL业务描述语言，例如：流程语言BPEL, 报表中延续的EXECL公式，数据库的SQL语言等等。用户通过DSL语言来描述业务结构以及数据信息，然后将DSL交由引擎去执行，从而有效实现业务与代码的解耦。这种技术在低代码平台中应用还是比较广泛的，在企业级低代码平台应用中更是标配。

结构组成

出码实施过程

​

引擎模式优点：

引擎模式是将业务模型输出为“DSL”这种中间语言，这种方式很好的解决了模型的二次维护与可逆性输出，在通用性的功能以及技术细节处理也相对更完善，能给直接用户带来更好的使用感受，在项目的重构以及后期维护方面也有不错的表现。

引擎模式缺点：

（1）易用性缺失，对使用者技术要求太高：

引擎模式有着诸多的优势，但在低代码平台除了需要强劲的功能支持以及扩展性支持外，还需要兼顾其易用性，对于低代码平台的核心用户主要还是定位在泛开发者而非专家型程序员。多引擎的设计会随着引擎细分越多、功能越强大、对于开发者而言所需的专业领域也会越宽泛。集成二次开发要求也会越来越强。而多引擎模式下所推崇的中台模式、APAAS平台初衷虽是为了更好的解耦应用实现微服务架构。但在一定程度上与低代码平台泛开发者定位是背道而驰的。往往在企业应用中往往是一旦建立起来中台，APAAS应用就成为了巨无霸的存在，使得业务缺少灵活性，技术架构更是僵硬不堪。

（2）构建过程复杂，不适合简单应用

引擎模式下，业务功能拆分会比较细，这种拆分对于构建复杂应用是有益处的，但在日常企业应用开发中在大多数的应用功能，往往是类似于：“实验数据上报”、“仪器设备管理”等等只在相对封闭的环境下使用的小功能。对于这种简单应用，引擎的功能就会显得过于强大。而其中包含的隐形规则和设计要求更使得普通开发者无所是从。

（3）引擎扩展困难

业务应用往往是复杂多变的，对引擎的要求也会多种多样，有的时候功能强大和业务实用是两个概念。单纯依靠引擎功能的无限穷举扩充来达避免业务代码对引擎的侵入有的时候会适得其反。适当的外延API允许开发者进行深度的调用开发是大多数引擎的策略。但要使用好这一策略其实并不容易，需要开发者提出了对引擎结构具备相当的熟练程度。者一点往往成为引擎模式下最大的拦路虎。

（3）DDD领域驱动设计（出码为DDD领域设计驱动语言）

领域域驱动设计(简称 ddd)概念来源于2004年著名建模专家Eric Evans 发表的他最具影响力的书籍:《领域驱动设计——软件核心复杂性应对之道》（Domain-Driven Design –Tackling Complexity in the Heart of Software），简称Evans DDD，在DDD中涵盖了业务需求分解方法，项目工程管理方法，以及其通过仓储库、领域模型等一些列概念的定义来达到其高聚合、低耦合的设计目的。

域驱动设计早期是作为软件架构设计的基础理论模型，是架构师的理论必修课。但在低代码应用中，根据DDD驱动设计模型的低代码工具则使得普通的开发者也可以设计出优秀的软件作品。这使得支持DDD理论模型成为了新一代的低代码平台理论标杆。而一系列领域模型工具的出现也大幅的降低了领域驱动设计的门槛。

领域建模模型：

DDD领域驱动模式优点：

（1）简单业务与复杂引擎业务统一模型支持

领域驱动模式，是代码生成与引擎模式的加强版。在领域驱动模型中各个引擎的功能，通过通用域、支撑域等领域模型进行了更高阶的包装与描述。开发者不再单独的围绕着独立的引擎API来完成开发,而是统一到领域服务与领域事件中使用统一的领域工具完成配置应用，而简单单一的业务模型也可以通过仓储模版构建复合领域模型聚合实体库，最终统一到独立的自定义用户域服务，开发者在基于领域模型时可以有机的将二者串联起来。的以便于业务逻辑与具体实现的分离。而统一的语言环境支持则允许领域服务可直接触及各引擎的DSL规则，方便于在领域事件中有机的完成各引擎的协同工作。

（2）以业务应用为中心建模高聚合应用

领域建模设计理念上是以具体的“业务模型”为基础的，其对应的出码输出物也是可直接运行的业务代码。这一点得益于其高聚合的设计，但同时也为低代码平台向无代码过渡提供了有力的建模理论支持与技术支撑。

​

（3）模块间的低耦合设计

DDD领域驱动设计在强调业务主导的同时，也更注重元围绕着业务主体流程及数据的元数据以及元元数据的支持，在主体业务之外采用元数据以及元元数据模型来描述业务源本身关联的事件、动作、交互展现等等。这使得业务本身的隔离性会更优秀，业务模块的之间的关联关系也更清晰。在设计业务关联以及实现时只需要关心业务本身的关联即可，而对于其他的事件，展现交互等统一作为元数据与元元数据处理实现解耦应用。

元元数据配置

​

​

DDD领域驱动模式缺点：

领域驱动设计高度抽象隔离了业务实现，但其作为一个新型的设计模式。对应的工具以及开发者生态还相对匮乏，对于大多数已经通过原生代码完成集成的业务模块以及基于引擎DSL语言的业务模型而言，元数据以及元元数据的剥离还需有待时日。

二，OneCode低代码引擎出码设计

OneCode低代码引擎是一款基于DDD驱动设计的通用低代码引擎。OneCode 采用JAVA作为原生语言，通过Java元数据注解方式，实现了一套完整通用领域驱动元数据模型。并且针对领域模型的元数据以及支撑元数据应用的元元数据提供了完整的配置管理以及元数据出码设计。开发者只需要引入OneCode元数据注解包，添加相应的元数据注解即可通过OneCode低代码引擎渲染输出为领域模型应用。

（1）OneCode 元数据注解

​

（2）OneCode 元数据注解读取即可视化编辑

​

（3）通用领域模型元数据设计

​

（4）页面设计器

简单易操作，一个稍有经验的高级程序员即可完成整套的基础模板设计，在经过模板输出后可以大幅降低普通程序员的劳动强度。

但缺点也很明显：

首先由于模型设计过程中过于简单，缺少元数据以及元元数据属性的支撑，在代码生成时需要更高级的属性支持时只能在模板中去丰富，这就造成代码模板会被严重污染大幅降低通用性，在真实使用过程中往往会出现一个项目一套模板甚至一个程序员都有一套只有的模板的囧局。这使得项目可维护性大幅降低。另外代码在代码生成后，多数情况下还需要进行一些二次补充和修改。但这些过程中是不可逆的，这使得代码生成只能在项目初始构建的时候使用，对于功能扩展或者代码重构都无法发挥其应用的作用。

小结：

单纯的代码生成模式如果纯粹作为程序员或者微型项目组作为代码工具使用尚可。在早期低代码平台中也比较常见于各种行业模板等应用，但随着技术进步，这种方式正在逐步被淘汰。

（2）引擎驱动模式（出码为DSL）

引擎驱动模式最早来起源于“中间件”设计，其设计目的是将大量具有通用意义的业务逻辑进行抽象包装，提供独立的数据模型，驱动模式再根据业务特性，定义出特定的DSL业务描述语言，例如流程语言BPEL, 报表中延续的EXECL公式，数据库的SQL语言等等。用户通过DSL语言来描述业务结构以及数据信息，然后将DSL交由引擎去执行，从而有效实现业务与代码的解耦。这种技术在低代码平台中应用还是比较广泛的特别是面向企业应用的低代码平台应用更是标配。

结构组成

出码实施过程

​

引擎模式优点：

引擎模式是将业务模型输出为“DSL”这种中间语言，很好的解决了，模型的二次维护与可逆性输出。同时引擎模式下，通用性的功能以及技术细节处理也会更完善，能给直接用户带来更好的使用感受。在项目的重构以及后期维护方面也有很好的解决方案。

引擎模式缺点：

易用性缺失，对使用者技术要求太高：引擎模式有着诸多的优势，但在低代码平台除了需要强劲的功能支持以及扩展性支持外，还需要兼顾其易用性，对于低代码平台的核心用户主要还是定位在泛开发者而非专家型程序员。多引擎的设计会随着引擎细分越多，功能越强大所需的专业领域会越宽泛，随之而来的就是对开发者的集成二次开发要求也会越来越强。所谓的中台模式、APAAS,在一定程度上与低代码平台是有些背道而驰。中台模式，APAAS模式初衷是为了更好的解耦应用实现微服务架构。但在企业应用中往往是一旦建立起来，中台，启用APAAS就成为了巨无霸的存在，使得业务缺少灵活性，技术架构更是僵硬不堪。

构建过程复杂，不适合简单应用

引擎模式下，功能业务功能拆分会比较细，这种才分对于构建复杂应用是有益处的，但在日常企业应用开发中，往往是类似于，实验数据上报、仪器设备管理等等只在相对封闭的环境下使用的小功能。对于这种简单应用各个引擎的功能就会显得过于强大繁琐。而其中包含的阴性规则和设计要去更使得普通开发者无所侍从。

引擎扩展困难

业务应用往往是多变性的，对引擎的要求也会多种多样，有的时候功能强大和业务实用是两个概念。依靠引擎功能的无限功能穷举扩充配置来达到避免代码对引擎的侵入有的时候会适得其反。适当的外延API允许开发者进行深度的调用开发是大多数引擎的基础策略。但要使用好这一策略则对开发者提出了更高的要求。在实际使用中最大的拦路虎也是来自于引擎的扩展应用。

（3）DDD领域驱动设计（出码为DDD领域设计驱动语言）

域驱动设计(简称 ddd)概念来源于2004年著名建模专家Eric Evans 发表的他最具影响力的书籍:《领域驱动设计——软件核心复杂性应对之道》（Domain-Driven Design –Tackling Complexity in the Heart of Software），简称Evans DDD，在DDD中涵盖了业务需求分解方法，项目工程管理方法，以及其通过仓储库、领域模型等一些列概念的定义来达到其高聚合、低耦合的设计目的。

域驱动设计早期是作为软件架构设计的基础理论模型，是架构师的理论必修课。但在低代码应用中，根据DDD驱动设计模型的低代码工具则使得普通的泛开发者也可以设计出优秀的软件作品。这使得支持DDD理论模型成为了新一代的低代码平台理论标杆。

领域建模模型：

DDD领域驱动模式优点：

简单业务与复杂引擎业务统一模型支持

领域驱动模式，是代码生成与引擎模式的加强版。在领域驱动模型中将各个引擎的功能，通过通用域、支撑域等领域模型进行了更高阶的包装与描述。开发者不再单独的围绕着独立的引擎来完成建模与开发而是统一到领域服务与领域事件中，同时独立单一的业务模型也允许用户通过自定义的代码引擎的方式完成简单业务的代码生成构建最终统一到用户独立的仓储库以便于业务逻辑与具体实现的分离。而统一的语言环境支持则允许领域服务可直接触及各引擎的DSL规则，方便于在领域事件中有机的完成各引擎的协同工作。

以业务应用为中心建模高聚合应用

领域建模设计理念上是从业务本身建模开始，其对应的出码输出物也是可直接运行的业务代码。这一点得益于其高聚合的设计，但同时也为低代码平台向无代码过渡提供了有力的建模理论支持与技术支撑。

​

模块间的低耦合设计

DDD领域驱动设计在强调业务主导的同时，也更注重元围绕着业务主体流程及数据的元数据以及元元数据的支持，在主体业务之外采用元数据以及元元数据模型来描述业务源本身关联的事件、动作、交互展现等等。这使得业务本身的隔离性会更优秀，业务模块的之间的联系也更清晰。在设计业务关联以及实现时只需要关心业务本身的关联即可，而对于其他的事件，展现交互等统一作为元数据与元元数据处理实现解耦应用。

元元数据配置

​

​

DDD领域驱动模式缺点：

领域驱动设计高度抽象隔离了业务实现，但其作为一个新型的设计模式。对应的工具包括生态还相对匮乏，对于大多数已经通过远程代码完成集成的业务模块或者独立的引擎模型而言，对于元数据以及元元数据的剥离还需有待时日。

二，OneCode低代码引擎出码设计

OneCode低代码引擎是一款基于DDD驱动设计的通用低代码引擎。OneCode 采用JAVA作为原生语言，通过Java元数据注解方式，实现了一套完整通用领域驱动元数据模型。并且针对领域模型的元数据以及支撑元数据应用的元元数据提供了完整的配置管理以及元数据出码设计。开发者只需要引入OneCode元数据注解包，添加相应的元数据注解即可通过OneCode低代码引擎渲染输出为领域模型应用。

（1）OneCode 元数据注解

​

（2）OneCode 元数据注解读取即可视化编辑

​

（3）通用领域模型元数据设计

​

（4）页面设计器