传统软件行业入局低代码关键技术分析

前言

近几年得益于，前端技术的突飞猛进，以及云计算的高速发展使得传统软件行业加速了技术迭代，大多数具有一定规模的传统软件公司都在跑步入局低代码。本文将从传统软件企业转型低代码应用方面做一个分析说明。

低代码关键技术

一，可视化技术选型

可视化技术是低代码的标志性技术之一，在传统软件应用中沉淀与积累使得软件的组件粒度规范而细腻，但过于精益求精也使得配置与管理都具有较高的技术难度。而低代码的可视化技术则可以将这些将规范应用更直观，管理更透明。使得“管理与配置”能够非常有效的向非专业技术人员递进传递。使得“业务积累与技术资产”得到了更高层度的激活。

但这与低代码的通用可视技术还是有比较明显的区别。在传统软件的可视化中，其实更应该遵循下图三步走的策略：

企业软件可视化过程

第一步首先要做的是数据信息，业务整合，提取转换业务模型。

第二步根据转换的业务模型参数化流程化配置化初步建立可视化“规划”以及可视化筹建计划。

最后一步也是最关键的一步则是将业务规划技术规划统一构建具有自身业务特点的领域驱动模型设计（DDD）形成高阶的可视化组件，逐步形成技术赋能。

二，响应式低代码框架选型

企业在构建自有的低代码框架时，多数都会考虑“数字底座”以及apaas 模式。但真正在构建的时候往往又容易流于“概念”。但真正在选则时更应该考虑的其实是基于“实时响应式”的“数智”底座。实时响应式的技术架构不但能很好的支持apaas的服务应用，同时也是天然的数字底座基础。但其面向高阶DDD领域驱动模型设计则可以更好向后兼容。

三，DevOps运维及原生开发支持

（1）应用渐进过程特殊需求

在企业级应用中，低代码作为新生的事务。必然会先从一些边缘业务开始，逐步向核心业务靠拢。而有实力尝试低代码引擎这种新技术的企业，多数都具备了相对完善的发布和管理的流程。对每一个应用的上线运行都有比较严格的流程安全规范。低代码应用如果仍然采用传统部署方式上线则需要根据企业的自身的应用发布测试流程进行整合，完成代码入库、版本管理，发布脚本，测试脚本等等众多技术性的要求。这显然与低代码本身的设计理念相悖，同时这些定制化也会大幅增加平台服务方与用户方工作量。解决这一问题最简单的方式便是提供独立的DevOps支持，特事特办，针对轻应用的特点，提供独立的运行、测试、发布部署环境支持。在企业原有服务中作为一个独立的服务中间件。

（2）数据安全以及应用安全需求

在企业应用中有很大一部分是不能对外的内部企业应用。特别是一些金融、政务政务应用甚至需要独立的内部网络来支持，这些应用极端情况下甚至只能通过光盘等物理介质来完成应用的更新。这在一定程度上对于应用的部署以及程序版本、数据版本提供了更高的要求，特别是一些权限设定审批流程等业务配置由于需要在真实数据下来才能完成设置，这就需要在发布完成后还需要支持发布环境下的二次配置。

（3）工程发布

工程发布，需要三方面的资源做支撑，分别是用户通过设计完成的页面及功能交互，通过特定的特定的出码模板完成相应的技术栈前端转换形成的前端页面目录。而后端应用则根据则是用户通过基础数据建模形成的领域模型文件，这些领域模型文件通常会按照，资源库、支撑域工程域等模型方式来独立打包方便后期版本管理及个体更新。另外第三块则是方便工程启动运行以及访问控制，对外暴露监控等相关的工程配置信息。

四，独享资源SAAS 多租户支持

多租户支持看似一个业务虚拟化的需求，但实质上则是数据底层的隔离以及服务隔离技术的体现。在成熟的IAAS层隔离技术下，PAAS层多数已经实现了无状态的服务提取，在企业软件的通用层特别是低代码应用中，对于单一职责的到爆模式则是新型的独享资源SAAS多租户的模式。

（1）服务打包模型

低代码应用中如果要具备完整的建模以及对外应用管理功能，就必然会涉及到后端数据建模以及基础的逻辑编排功能，不同的平台面向的开发者群体也会有所不同，有以解决简单数据的增删改查为目的初级数据库建模应用也有面向专业开发者的领域建模应用。但不管哪一类的平台，在打包编译输出的时候。通常会采用一下模型来完成。

（2）服务模型接口描述（虚拟地址能力）

服务模型接口描述，通常采用的是Rest的web服务模式，每个工程会设定相应的命名控件，然后根据具体页面的服务地址进行重新的编排以树形的的结构来管理和展示webapi结构。

OneCodeAPI模型

在接口描述中通常会包含：

URL地址：标识可通过WEB访问的地址。

页面绑定服务对象：当通过数据接口获取数据后将数据和前端的容器、列表、表格、树形等具体的组件进行绑定。

后端接收绑定：当前端数据发生变化时通过ajax或者表单提交等方式将数据同步到后端数据模型。

服务模型接口描述，在打包应用中是一个必备的选项，在完成打包后需要通知应用服务器完成相关的服务注册同时也为应用服务权限等提供策略服务支撑。

（3）通用域模型概览

通用域模型

（4）用户模型

在应用建模中，用户模型是所有应用中必选项。在低代码建模应用中，多数也都是在基于用户自有体系的模型中来完成，如宜搭中内置的钉钉组织机构模型，微搭使用的企业微信模型。而在稍具规模的企业中都会有适应性的统一组织机构模型来支撑。

组织机构模型参数化设计

在低代凭条设计中，除了要通过响应的API获取相关信息外还需要将其应用参数化，更好的和低代码应用结合起来。而在应用发布的过程中也需要根据具体的领域模型来配套相关的环境构建。

（5）权限模型

在业务应用中权限模型是系统的血液与灵魂，控制着数据的流向确保数据安全正确的运行。而在低代码平台中随着组件化成都的进一步提升，则需要耕细粒度的权限细分，来提升应用体验。