都在吹低代码，我们找已“发育”十多年的UBML聊了聊

喜欢就关注我们吧！

出品 | OSCHINA

文 | 一君

近日，低代码建模语言 UBML 正式开放源代码。UBML 相当于低代码开发平台的 SDK，是浪潮 iGIX 低代码建模体系的内核。

低代码的概念被认为最早衍生于上世纪 80 年代的“第四代编程语言”4GL，紧接着是 2000 年出现的 VPL 可视化编程语言。与早期这些开发环境类似，现如今流行的低代码开发平台基于模型驱动设计，自动代码生成和可视化编程的原理，可节省开发投入。

基于模型驱动，各个低代码平台之间的较量实际也成了对不同模型的考验。UBML 团队认为，目前有一些小规模厂商或成长型企业的低代码平台，受限于资源投入，在架构设计和功能覆盖上可能会有所不足；互联网公司的低代码平台又缺少对于企业需求的深度理解；而管理软件厂商的低代码平台更贴近企业的实际需求，依靠浪潮云 ERP 在企业服务市场的积淀，UBML 模型的丰富度和深度是其主要优势。

同时 UBML 也提出了“模型即源码”的发展理念。UBML 包含开发语言无关性的建模标准（UBML-Standard），内置了基于 UBML 标准的全栈业务模型（UBML-Models），并提供了可与模型进行全生命周期交互的开发服务与套件（UBML-SDK）及支撑模型运行的运行时框架（UBML-Runtime）。

目前 UBML-Standard、UBML-Models，以及面向后端开发的核心模型BE（Business-Entity）、VO（View-Model）和服务模型中的 EAPI（External-API）部分已经开源，后续将开放出更多组件。借此机会，OSCHINA 邀请 UBML 开发团队，请他们分享 UBML 的一些设计理念，适用场景及技术特性，并解答开发者对 UBML 及低代码概念的一些疑问。

用 UBML 能做什么？

低代码开发概念发展至今，已经分化出两个不同的方向，一是为开发人员服务，通过可视化拖拽的方式完成大部分工作，开发者只需要编写少量的代码，也就是通常所说的低代码开发平台；二是面向无编程基础的人群，主要围绕企业数据和业务管理需求，通过可视化方式设计数据结构、前端界面等，不需要任何代码编程，也被称为零代码开发。

UBML 主要面向的是低代码开发平台的开发者，可应用于软件设计、开发、测试、发布、部署的各个环节。

UBML 核心开发者郝志北介绍，低代码平台也应是按照“二八原则”来设计的。对于基本的增删改查等常规的业务处理，都是不需要手写代码的，比如一个简单的订单业务，从后端建表、业务逻辑开发到开放 RESTful API，再到前端的界面展现，这些功能都可以通过低代码的方式自动完成。而一些很难用规则去表达的领域化的业务逻辑，算法、规则等，需要开发人员手工扩展。

UBML 默认提供的 SDK 与 Runtime 是基于 Java 实现的，此外，UBML 还可通过开发语言无关性的代码标准 UBML-Standard，支持跨语言开发需求。UBML-Standard 是一套高层次领域模型建模体系，其中的模型是由 DSL 描述的（如JSON、XML），通过一份 UBML 模型，可根据具体要求，生成或动态解析为不同开发语言（比如 Java、JS、C# 等）运行。

图：UBML 提供的 JIT 即时编译机制

在整个工业互联网技术体系中，UBML 被设计用于aPaaS （应用程序开发平台）层，属于 IaaS 和 SaaS 之间的 PaaS 层。基于浪潮的经验与积累，UBML 目前支持的建模范围以及提供的配套组件，主要是面向工业应用中的“经营管理类”应用。

未来， UBML 也打算延伸和扩展在 OT 侧的能力，在 IoT、智能化开发、数据驱动型应用等多个方向深入发展，通过浪潮、开放原子开源基金会和广大社区开发者多方协同共建，探索工业互联网领域的完整解决方案。

模型即源码

UBML 基于“模型即源码”的理念，将模型视作源代码进行工程化管理，可以与主流研发过程管理工具进行集成，支持 DevOps。同时，UBML 还提供了几十种涵盖从前端到后端的全栈业务模型体系。

针对如何理解“模型即源码”的理念，以及各种模型之间的配合使用，郝志北做了更详细的解释。

“模型即源码”的理念是指，UBML 将模型本身也视作源码的一部分进行统一管理，可以将包含模型在内的所有开发产物与 DevOps 流水线进行集成，打通开发-构建-打包-测试-部署完整的流程，模型对应的制品也会部署到对应的制品库中进行统一管理。

全栈业务模型体系

对于 UBML 的 “全栈模型体系”，郝志北表示，低代码平台的核心能力就是模型的丰富度和沉淀的厚度，即表述能力和业务沉淀能力。

UBML 从应用分层架构出发，结合了微服务架构、领域驱动设计理念，对各层做了细分与抽象，形成了覆盖持久化层、领域层、业务流程层、BFF 层、UI 层的全栈模型体系，这几十种模型中，不同模型承担着相对单一的职责，在建模开发的过程中，各模型上下文清晰；便于模型间集成并对公共内容进行复用，而且模型体系具有良好的扩展性。

以开发一个相对完整的简单应用为例来进行说明，包含简单前端界面、后台逻辑，同时提供标准 RESTful API 供调用集成。

首先对场景中涉及到的后端实体进行建模，这里用到的模型是业务实体（BE，Business-Entity），新建 BE 时，会自动创建实体对应的数据库表模型-数据库对象（DBO，DataBase-Object），有了实体作为数据源后，还需新建一个前端展示层的模型-表单（Form），表单上展示的字段信息可能经由 BE 字段裁剪或由多个 BE 编排而来，为实现这个效果，需要视图模型（VO，View-Model），对单个或多个 BE 进行裁剪或组装，创建 VO 时还会自动创建出供前端调用的、描述 RESTful API 的模型-外部服务（External-API）。

基于这几种模型，就可以完成一个最基本的开发流程。

值得一提的是，UBML 建模体系中的模型能够与 DDD（领域驱动设计） 分层架构中的几个核心概念是对应匹配的：

业务实体（Business-Entity,BE）对应 DDD 中领域层的概念，提供了实体、业务字段（对应 DDD 值对象）的实体结构描述以及业务实体操作（对应 DDD 的领域服务描述），承载了核心业务逻辑；

视图对象（View-Model，VO）对应应用服务层，承载了具体的业务场景，可以组装多个业务实体或者作为业务实体的子集，提供了面向不同业务场景的建模封装；

表单（Form，FRM）对应展现层：提供 UI 界面建模能力；

此外 UBML 还提供了内部服务（Internal-API,IAPI）、外部服务（External-API,EAPI）、持久化层（Database-Object,DBO）等基础设施的建模能力。

 图：UBML 对于 DDD 架构的落地实践

“我们认为一个系统需要有一套可持续沉淀的、承载后端核心业务逻辑的框架，这套框架可以持续沉淀和积累领域知识，是相对稳定的，可以很好解决前端演化更快的问题，支撑企业级骨干业务系统，DDD 设计理念与此思路是可以很好匹配的”

UBML 前身及开源规划

实际上，UBML 的历史最早可以追溯到 2004 年。

2004 至 2019 年间，浪潮的上一代低代码开发平台 GSP 就采用了模型驱动的低代码开发技术，其内置的模型体系是 UBML 的前身。

2019年，浪潮基于云原生、前后端分离、领域驱动设计、跨平台等架构与设计理念，形成了 UBML 低代码建模体系，并应用到了新一代产品 iGIX 当中。

目前 UBML 已从 iGIX 中进行剥离并捐赠给开放原子开源基金会，启动 iGIX 开源进程。

“首先期望通过浪潮、基金会、社区多方努力，将 UBML 建成低代码建模领域的事实标准，后续我们会开放 UBML-Designer 等更多低代码工具，基于 UBML 形成 Open iGIX 项目，形成社区版低代码开发平台，建立广泛的开发者、模型、应用生态，商业版主要的是在技术支持和部分高级特性上与社区版有所差异。”郝志北介绍，Open iGIX 将主要面向企业级应用的开发人员，包括专业开发人员和非专业开发人员，比如实施顾问、业务专家等。

目前，UBML 开发团队也规划了一系列的开源运营活动：2021 年，UBML 将会举行线上线下的宣讲与布道活动，为社区开发者进行技术赋能；也会广泛邀请业内技术专家为大家传道授业、答疑解惑；同时也计划与国内高校联合举办 UBML 走进校园的活动；

后续，随着 UBML Designer 等更多工具的开源和社区版低代码开发平台的逐步开放，其团队也将举办 Open iGIX 应用开发大赛，帮助开发者都能快速高效地使用 UBML 构建属于自己的应用。

低代码是伪命题吗？

虽然低代码概念已经流行多年，但质疑低代码的声音一直存在。如低代码的模式是否会存在缺陷因此制约使用者的工作？低代码发展下去是否会造成开发人员失业等等？作为低代码建模语言的 UBML 自然也会面对这些问题。

郝志北认为，低代码开发平台为开发者提供了可视化建模工具，通常还提供广泛的平台能力，可以屏蔽日常编码中的大量重复机械工作。

如在 UBML 提供的源码生成型模式中，自动生成的程序源码是直接提供给开发者供其使用或扩展的，这对于编码工作量的降低是切实可见的。因此，低代码开发方式实际上是给了开发者一种更高效率的选择，它应作为一种开发利器，而并非是一种制约。

此外，软件的生产效率是从“软件作坊”->“软件工厂”进行转换的，其中软件自动化的趋势是不可取代的，这不仅代表着软件生产力的提高，同时带来了很多价值和机会。比如可以让不同层次的开发者分工更明确，可省去重复化的工作，是把开发人员从繁琐重复的低效工作中解放出来，聚焦于价值更大的有创造性、且不可复制的工作。

觉得不错，请点个在看呀