前言

低代碼應用大幅降低了開發(fā)者的門檻，使得更多更大范圍的群體能夠參與到軟件開發(fā)過程中。但前期應用中多數(shù)還是應用還是建立在特定的平臺上的功能擴展。 這種先平臺后應用的模式直接限制了低代碼平臺的應用范圍，于是處于頭部的低代碼平臺都紛紛推出了允許客戶定制導出，獨立發(fā)布部署的輕應用模式。使客戶在完成基礎(chǔ)的低代碼模型以及應用開發(fā)后，可以快速的導出為單獨的應用，根據(jù)需求部署在自己的內(nèi)網(wǎng)或公共云虛擬主機中。本文將從低代碼服務導出發(fā)布這個角度結(jié)合OneCode的DevOps設計來闡述一下低代碼的服務發(fā)布設計。

一，企業(yè)為什么需要有獨立部署支持

（1）應用漸進過程特殊需求

在企業(yè)級應用中，低代碼作為新生的事務。必然會先從一些邊緣業(yè)務開始，逐步向核心業(yè)務靠攏。而有實力嘗試低代碼引擎這種新技術(shù)的企業(yè)，多數(shù)都具備了相對完善的發(fā)布和管理的流程。對每一個應用的上線運行都有比較嚴格的流程安全規(guī)范。低代碼應用如果仍然采用傳統(tǒng)部署方式上線則需要根據(jù)企業(yè)的自身的應用發(fā)布測試流程進行整合，完成代碼入庫、版本管理，發(fā)布腳本，測試腳本等等眾多技術(shù)性的要求。這顯然與低代碼本身的設計理念相悖，同時這些定制化也會大幅增加平臺服務方與用戶方工作量。解決這一問題最簡單的方式便是提供獨立的DevOps支持，特事特辦，針對輕應用的特點，提供獨立的運行、測試、發(fā)布部署環(huán)境支持。在企業(yè)原有服務中作為一個獨立的服務中間件。

（2）數(shù)據(jù)安全以及應用安全需求

在企業(yè)應用中有很大一部分是不能對外的內(nèi)部企業(yè)應用。特別是一些金融、政務政務應用甚至需要獨立的內(nèi)部網(wǎng)絡來支持，這些應用極端情況下甚至只能通過光盤等物理介質(zhì)來完成應用的更新。這在一定程度上對于應用的部署以及程序版本、數(shù)據(jù)版本提供了更高的要求，特別是一些權(quán)限設定審批流程等業(yè)務配置由于需要在真實數(shù)據(jù)下來才能完成設置，這就需要在發(fā)布完成后還需要支持發(fā)布環(huán)境下的二次配置。

二，工程發(fā)布文件結(jié)構(gòu)總綱

編輯切換為居中

添加圖片注釋，不超過 140 字（可選）

工程發(fā)布，需要三方面的資源做支撐，分別是用戶通過設計完成的頁面及功能交互，通過特定的特定的出碼模板完成相應的技術(shù)棧前端轉(zhuǎn)換形成的前端頁面目錄。而后端應用則根據(jù)則是用戶通過基礎(chǔ)數(shù)據(jù)建模形成的領(lǐng)域模型文件，這些領(lǐng)域模型文件通常會按照，資源庫、支撐域工程域等模型方式來獨立打包方便后期版本管理及個體更新。另外第三塊則是方便工程啟動運行以及訪問控制，對外暴露監(jiān)控等相關(guān)的工程配置信息。

三，資源（物料）目錄樹

?

（1）用戶工程目錄樹：

?

用戶目錄樹是由用戶自行建立，同時也是工程編輯的入口，用戶通過目錄配置頁面路由。串聯(lián)相關(guān)功能。同時一些個性化的定義也有此導入。

（2）前端支撐庫

主要跟開發(fā)者出碼時選擇的技術(shù)棧有關(guān)，通常也是作為導出模板配置的基本屬性。在基礎(chǔ)基礎(chǔ)棧中會配合相應的調(diào)試以及運行集成頁面，達到開箱即用的匹配能力。

?

（3）物料庫支撐目錄

物料庫是低代碼應用中最具創(chuàng)新的一塊應用，也是在組件化以及可視化應用中對開發(fā)者最具吸引力的一塊。

物料庫除了具備基本的導入維護功能意外，在發(fā)布時能根據(jù)開發(fā)者的二次選擇進行自動裝載壓縮編譯也是低代碼發(fā)布管理的一個重要的環(huán)節(jié)。

?

?

?

（4）外部庫引入

低代碼應用中，在涉及到一些統(tǒng)計報表、工業(yè)組態(tài)設計，計算表格應用時。通常會采用引入獨立的第三方JS代碼庫，這些代碼庫在很大程度上簡化了配置，增強了應用的集成化設計。但每個組件在發(fā)布與編譯時都會有自身的打包規(guī)則。在設計打包編譯系統(tǒng)時需要獨立配置來完成。在OneCode 就源引了，200多種獨立的組件庫補充基礎(chǔ)組件的不足，并且根據(jù)其基本的代碼打包規(guī)則進行了打包適配。

?

?

?

四，后端服務

（1）后端打包結(jié)構(gòu)總覽

低代碼應用中如果要具備完整的建模以及對外應用管理功能，就必然會涉及到后端數(shù)據(jù)建模以及基礎(chǔ)的邏輯編排功能，不同的平臺面向的開發(fā)者群體也會有所不同，有以解決簡單數(shù)據(jù)的增刪改查為目的初級數(shù)據(jù)庫建模應用也有面向?qū)I(yè)開發(fā)者的領(lǐng)域建模應用。但不管哪一類的平臺，在打包編譯輸出的時候。通常會采用一下模型來完成。

?

（2）服務模型接口描述

服務模型接口描述，通常采用的是Rest的web服務模式，每個工程會設定相應的命名控件，然后根據(jù)具體頁面的服務地址進行重新的編排以樹形的的結(jié)構(gòu)來管理和展示webapi結(jié)構(gòu)。

?

編輯切換為居中

OneCodeAPI模型

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

URL地址：標識可通過WEB訪問的地址。

頁面綁定服務對象：當通過數(shù)據(jù)接口獲取數(shù)據(jù)后將數(shù)據(jù)和前端的容器、列表、表格、樹形等具體的組件進行綁定。

后端接收綁定：當前端數(shù)據(jù)發(fā)生變化時通過ajax或者表單提交等方式將數(shù)據(jù)同步到后端數(shù)據(jù)模型。

服務模型接口描述，在打包應用中是一個必備的選項，在完成打包后需要通知應用服務器完成相關(guān)的服務注冊同時也為應用服務權(quán)限等提供策略服務支撐。

五，用戶工程領(lǐng)域模型

在低代碼服務應用中，有很大一部分應用時建立在獨立而完整的數(shù)據(jù)模型之下的，相對成熟的低代平臺都會允許開發(fā)者，使用領(lǐng)域模型工具來全新的構(gòu)建業(yè)務面模型。

（1）Repository資源庫

在領(lǐng)域模型中，Repository資源庫也成為基礎(chǔ)設施層。在低代碼平臺中構(gòu)建基礎(chǔ)應用時多數(shù)都是從數(shù)據(jù)庫表等基礎(chǔ)設施層來構(gòu)建面向?qū)ο蟮臄?shù)據(jù)庫表設計。在應用打包的過程中需要根據(jù)用戶選擇的基礎(chǔ)技術(shù)棧以及模板庫來完成基礎(chǔ)設施層的代碼出碼及編譯工作。

?

?

?

（2）Aggregate聚合應用

Aggregate聚合是領(lǐng)域模型非常重要的一塊，也是抽象度比較高的。DNA其在低代碼的應用中卻非常廣泛，在低代碼中大量的頁面動作以及數(shù)據(jù)事件都是需要與后臺交互才能完成的。而這種交互過程是非常復雜而繁瑣的，如果只是從前端來構(gòu)建將其分解為單個的前后臺交互調(diào)用，不但無端增加了學習及使用成本同時也讓前端頁面邏輯變得擁擠不堪。而聚合應用則更好的充當了這一橋梁作用。利用Aggregate Root（“聚合根“）將業(yè)務對象封裝成為可以直接操作的業(yè)務模型。將業(yè)務實體提升為“聚合實體”直接充當前后端數(shù)據(jù)模型的載體完成數(shù)據(jù)交互應用，而前端頁面相關(guān)的交互動作則直接封裝為聚合菜單動作。與前端API完全打通實現(xiàn)前端API的同步調(diào)用。

這種邏輯應用特別適合在低代碼平臺中作為邏輯編排的工具，在開發(fā)者編排相關(guān)邏輯的同時，同步將后端的Aggregate聚合應用創(chuàng)建出來，貫穿前端頁面同時關(guān)聯(lián)后端的Repository資源庫。

在模型進行發(fā)布和管理的時候，則需要根據(jù)具體的技術(shù)棧，來轉(zhuǎn)換為本地語言同步完成相關(guān)的前后臺代碼配置工作。這也是低代碼平臺編譯與發(fā)布中最難把握的一個地方。

?

?

?

?

（3）視圖路由

視圖路由是領(lǐng)域模型中，表示層中最重要的一種展現(xiàn)方式。低代碼平臺中最大的特點是組件化與可視化。表示層建模是其特有的優(yōu)勢，但這里提到的則是更為抽象的一種表示。即用戶在完成視圖繪制以及數(shù)據(jù)模型動作事件配置后，需要將可視化模型完成抽取，將頁面以及路由相關(guān)的模型來構(gòu)建領(lǐng)域模型中的表示層模型“視圖路由”同時將數(shù)據(jù)以及交互動作抽取為Repository資源層及Aggregate聚合應用層。然后再通過代碼工廠統(tǒng)一編譯輸出為獨立的可運行的工程代碼。

?

六，通用領(lǐng)域模型

（1）通用域模型概覽

（2）用戶模型

在應用建模中，用戶模型是所有應用中必選項。在低代碼建模應用中，多數(shù)也都是在基于用戶自有體系的模型中來完成，如宜搭中內(nèi)置的釘釘組織機構(gòu)模型，微搭使用的企業(yè)微信模型。而在稍具規(guī)模的企業(yè)中都會有適應性的統(tǒng)一組織機構(gòu)模型來支撐。

在低代憑條設計中，除了要通過響應的API獲取相關(guān)信息外還需要將其應用參數(shù)化，更好的和低代碼應用結(jié)合起來。而在應用發(fā)布的過程中也需要根據(jù)具體的領(lǐng)域模型來配套相關(guān)的環(huán)境構(gòu)建。

（3）權(quán)限模型

在業(yè)務應用中權(quán)限模型是系統(tǒng)的血液與靈魂，控制著數(shù)據(jù)的流向確保數(shù)據(jù)安全正確的運行。而在低代碼平臺中隨著組件化成都的進一步提升，則需要耕細粒度的權(quán)限細分，來提升應用體驗。

?

?

?

?

（4）知識資料庫

知識資料庫在企業(yè)應用中是一種特殊的存在，幾乎所有的業(yè)務應用系統(tǒng)都需要與其完成相應的集成，普通業(yè)務集成多局限在成文文檔的檢索以及歸檔，但在低代碼模型中由于其特殊的模型能力，則可以從元數(shù)據(jù)層次來統(tǒng)一規(guī)劃數(shù)據(jù)的聲明周期，從頁面、數(shù)據(jù)結(jié)構(gòu)、元數(shù)據(jù)本身多個層次構(gòu)建基于元數(shù)據(jù)模型的知識資料庫。實現(xiàn)全聲明周期的電子文件模型管理。

（5）門戶與消息

在互聯(lián)網(wǎng)低代碼應用中，體量最大的企業(yè)微信和釘釘都是從及時通訊逐步擴展到企業(yè)服務領(lǐng)域的。及時通訊以及企業(yè)門戶在企業(yè)中是入口的應用，在低代碼工程應用整合中會起到至關(guān)重要的位置。

七，支撐域模型

支撐域是企業(yè)核心中間件的核心邏輯層。是低代碼應用中必不可少的接入集成。這需要通過中臺獲取開放的接口的描述時，能夠快速的參數(shù)化相關(guān)應用，通過聚合能力接入低代碼平臺，而在部署打包時又可以通過特定語言的出碼設置，編譯為特定環(huán)境的適配代碼完成應用戶核心支撐與的緊密結(jié)合。

?

?

?

八，工程配置

（1）工程版本支持

?

（2）工程版本支持

?

（3）工程配置支持

?