前言

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

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

（1）應(yīng)用漸進(jìn)過(guò)程特殊需求

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

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

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

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

編輯切換為居中

添加圖片注釋?zhuān)怀^(guò) 140 字（可選）

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

三，資源（物料）目錄樹(shù)

?

（1）用戶工程目錄樹(shù)：

?

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

（2）前端支撐庫(kù)

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

?

（3）物料庫(kù)支撐目錄

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

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

?

?

?

（4）外部庫(kù)引入

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

?

?

?

四，后端服務(wù)

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

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

?

（2）服務(wù)模型接口描述

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

?

編輯切換為居中

OneCodeAPI模型

在接口描述中通常會(huì)包含：

URL地址：標(biāo)識(shí)可通過(guò)WEB訪問(wèn)的地址。

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

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

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

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

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

（1）Repository資源庫(kù)

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

?

?

?

（2）Aggregate聚合應(yīng)用

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

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

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

?

?

?

?

（3）視圖路由

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

?

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

（1）通用域模型概覽

（2）用戶模型

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

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

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

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

?

?

?

?

（4）知識(shí)資料庫(kù)

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

（5）門(mén)戶與消息

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

七，支撐域模型

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

?

?

?

八，工程配置

（1）工程版本支持

?

（2）工程版本支持

?

（3）工程配置支持

?