前言
低代码应用大幅降低了开发者的门槛，使得更多更大范围的群体能够参与到软件开发过程中。但前期应用中多数还是应用还是建立在特定的平台上的功能扩展。 这种先平台后应用的模式直接限制了低代码平台的应用范围，于是处于头部的低代码平台都纷纷推出了允许客户定制导出，独立发布部署的轻应用模式。使客户在完成基础的低代码模型以及应用开发后，可以快速的导出为单独的应用，根据需求部署在自己的内网或公共云虚拟主机中。本文将从低代码服务导出发布这个角度结合OneCode的DevOps设计来阐述一下低代码的服务发布设计。
一，企业为什么需要有独立部署支持
（1）应用渐进过程特殊需求
在企业级应用中，低代码作为新生的事务。必然会先从一些边缘业务开始，逐步向核心业务靠拢。而有实力尝试低代码引擎这种新技术的企业，多数都具备了相对完善的发布和管理的流程。对每一个应用的上线运行都有比较严格的流程安全规范。低代码应用如果仍然采用传统部署方式上线则需要根据企业的自身的应用发布测试流程进行整合，完成代码入库、版本管理，发布脚本，测试脚本等等众多技术性的要求。这显然与低代码本身的设计理念相悖，同时这些定制化也会大幅增加平台服务方与用户方工作量。解决这一问题最简单的方式便是提供独立的DevOps支持，特事特办，针对轻应用的特点，提供独立的运行、测试、发布部署环境支持。在企业原有服务中作为一个独立的服务中间件。
（2）数据安全以及应用安全需求
在企业应用中有很大一部分是不能对外的内部企业应用。特别是一些金融、政务政务应用甚至需要独立的内部网络来支持，这些应用极端情况下甚至只能通过光盘等物理介质来完成应用的更新。这在一定程度上对于应用的部署以及程序版本、数据版本提供了更高的要求，特别是一些权限设定审批流程等业务配置由于需要在真实数据下来才能完成设置，这就需要在发布完成后还需要支持发布环境下的二次配置。
二，工程发布文件结构总纲
编辑切换为居中
添加图片注释，不超过 140 字（可选）
工程发布，需要三方面的资源做支撑，分别是用户通过设计完成的页面及功能交互，通过特定的特定的出码模板完成相应的技术栈前端转换形成的前端页面目录。而后端应用则根据则是用户通过基础数据建模形成的领域模型文件，这些领域模型文件通常会按照，资源库、支撑域工程域等模型方式来独立打包方便后期版本管理及个体更新。另外第三块则是方便工程启动运行以及访问控制，对外暴露监控等相关的工程配置信息。
三，资源（物料）目录树
（1）用户工程目录树：
用户目录树是由用户自行建立，同时也是工程编辑的入口，用户通过目录配置页面路由。串联相关功能。同时一些个性化的定义也有此导入。
（2）前端支撑库
主要跟开发者出码时选择的技术栈有关，通常也是作为导出模板配置的基本属性。在基础基础栈中会配合相应的调试以及运行集成页面，达到开箱即用的匹配能力。
（3）物料库支撑目录
物料库是低代码应用中最具创新的一块应用，也是在组件化以及可视化应用中对开发者最具吸引力的一块。
物料库除了具备基本的导入维护功能意外，在发布时能根据开发者的二次选择进行自动装载压缩编译也是低代码发布管理的一个重要的环节。
（4）外部库引入
低代码应用中，在涉及到一些统计报表、工业组态设计，计算表格应用时。通常会采用引入独立的第三方JS代码库，这些代码库在很大程度上简化了配置，增强了应用的集成化设计。但每个组件在发布与编译时都会有自身的打包规则。在设计打包编译系统时需要独立配置来完成。在OneCode 就源引了，200多种独立的组件库补充基础组件的不足，并且根据其基本的代码打包规则进行了打包适配。
四，后端服务
（1）后端打包结构总览
低代码应用中如果要具备完整的建模以及对外应用管理功能，就必然会涉及到后端数据建模以及基础的逻辑编排功能，不同的平台面向的开发者群体也会有所不同，有以解决简单数据的增删改查为目的初级数据库建模应用也有面向专业开发者的领域建模应用。但不管哪一类的平台，在打包编译输出的时候。通常会采用一下模型来完成。
（2）服务模型接口描述
服务模型接口描述，通常采用的是Rest的web服务模式，每个工程会设定相应的命名控件，然后根据具体页面的服务地址进行重新的编排以树形的的结构来管理和展示webapi结构。
编辑切换为居中
OneCodeAPI模型
在接口描述中通常会包含：
URL地址：标识可通过WEB访问的地址。
页面绑定服务对象：当通过数据接口获取数据后将数据和前端的容器、列表、表格、树形等具体的组件进行绑定。
后端接收绑定：当前端数据发生变化时通过ajax或者表单提交等方式将数据同步到后端数据模型。
服务模型接口描述，在打包应用中是一个必备的选项，在完成打包后需要通知应用服务器完成相关的服务注册同时也为应用服务权限等提供策略服务支撑。
五，用户工程领域模型
在低代码服务应用中，有很大一部分应用时建立在独立而完整的数据模型之下的，相对成熟的低代平台都会允许开发者，使用领域模型工具来全新的构建业务面模型。
（1）Repository资源库
在领域模型中，Repository资源库也成为基础设施层。在低代码平台中构建基础应用时多数都是从数据库表等基础设施层来构建面向对象的数据库表设计。在应用打包的过程中需要根据用户选择的基础技术栈以及模板库来完成基础设施层的代码出码及编译工作。
（2）Aggregate聚合应用
Aggregate聚合是领域模型非常重要的一块，也是抽象度比较高的。DNA其在低代码的应用中却非常广泛，在低代码中大量的页面动作以及数据事件都是需要与后台交互才能完成的。而这种交互过程是非常复杂而繁琐的，如果只是从前端来构建将其分解为单个的前后台交互调用，不但无端增加了学习及使用成本同时也让前端页面逻辑变得拥挤不堪。而聚合应用则更好的充当了这一桥梁作用。利用Aggregate Root（“聚合根“）将业务对象封装成为可以直接操作的业务模型。将业务实体提升为“聚合实体”直接充当前后端数据模型的载体完成数据交互应用，而前端页面相关的交互动作则直接封装为聚合菜单动作。与前端API完全打通实现前端API的同步调用。
这种逻辑应用特别适合在低代码平台中作为逻辑编排的工具，在开发者编排相关逻辑的同时，同步将后端的Aggregate聚合应用创建出来，贯穿前端页面同时关联后端的Repository资源库。
在模型进行发布和管理的时候，则需要根据具体的技术栈，来转换为本地语言同步完成相关的前后台代码配置工作。这也是低代码平台编译与发布中最难把握的一个地方。
（3）视图路由
视图路由是领域模型中，表示层中最重要的一种展现方式。低代码平台中最大的特点是组件化与可视化。表示层建模是其特有的优势，但这里提到的则是更为抽象的一种表示。即用户在完成视图绘制以及数据模型动作事件配置后，需要将可视化模型完成抽取，将页面以及路由相关的模型来构建领域模型中的表示层模型“视图路由”同时将数据以及交互动作抽取为Repository资源层及Aggregate聚合应用层。然后再通过代码工厂统一编译输出为独立的可运行的工程代码。
六，通用领域模型
（1）通用域模型概览
（2）用户模型
在应用建模中，用户模型是所有应用中必选项。在低代码建模应用中，多数也都是在基于用户自有体系的模型中来完成，如宜搭中内置的钉钉组织机构模型，微搭使用的企业微信模型。而在稍具规模的企业中都会有适应性的统一组织机构模型来支撑。
在低代凭条设计中，除了要通过响应的API获取相关信息外还需要将其应用参数化，更好的和低代码应用结合起来。而在应用发布的过程中也需要根据具体的领域模型来配套相关的环境构建。
（3）权限模型
在业务应用中权限模型是系统的血液与灵魂，控制着数据的流向确保数据安全正确的运行。而在低代码平台中随着组件化成都的进一步提升，则需要耕细粒度的权限细分，来提升应用体验。
（4）知识资料库
知识资料库在企业应用中是一种特殊的存在，几乎所有的业务应用系统都需要与其完成相应的集成，普通业务集成多局限在成文文档的检索以及归档，但在低代码模型中由于其特殊的模型能力，则可以从元数据层次来统一规划数据的声明周期，从页面、数据结构、元数据本身多个层次构建基于元数据模型的知识资料库。实现全声明周期的电子文件模型管理。
（5）门户与消息
在互联网低代码应用中，体量最大的企业微信和钉钉都是从及时通讯逐步扩展到企业服务领域的。及时通讯以及企业门户在企业中是入口的应用，在低代码工程应用整合中会起到至关重要的位置。
七，支撑域模型
支撑域是企业核心中间件的核心逻辑层。是低代码应用中必不可少的接入集成。这需要通过中台获取开放的接口的描述时，能够快速的参数化相关应用，通过聚合能力接入低代码平台，而在部署打包时又可以通过特定语言的出码设置，编译为特定环境的适配代码完成应用户核心支撑与的紧密结合。
八，工程配置
（1）工程版本支持
（2）工程版本支持
（3）工程配置支持
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。