前言
低代碼應用大幅降低了開發者的門檻，使得更多更大范圍的群體能夠參與到軟件開發過程中。但前期應用中多數還是應用還是建立在特定的平臺上的功能擴展。 這種先平臺后應用的模式直接限制了低代碼平臺的應用范圍，于是處于頭部的低代碼平臺都紛紛推出了允許客戶定制導出，獨立發布部署的輕應用模式。使客戶在完成基礎的低代碼模型以及應用開發后，可以快速的導出為單獨的應用，根據需求部署在自己的內網或公共云虛擬主機中。本文將從低代碼服務導出發布這個角度結合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）工程配置支持
?
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
