今天準備再寫一篇關于低代碼開發平臺的文章，在前面講云原生整體解決方案的時候，我談到過低代碼開發平臺，但是對里面的一些核心組件以及組件間的集成沒有展開描述，而這些剛好是一個低代碼開發平臺設計和實現的關鍵內容。

[[360049]]

低代碼平臺概述

對于低代碼開發平臺，百度詞條有一個基礎定義，如下：

低代碼開發平臺（LCDP）是無需編碼（0代碼）或通過少量代碼就可以快速生成應用程序的開發平臺。通過可視化進行應用程序開發的方法（參考可視編程語言），使具有不同經驗水平的開發人員可以通過圖形化的用戶界面，使用拖拽組件和模型驅動的邏輯來創建網頁和移動應用程序。低代碼開發平臺在完成業務邏輯、功能構建后，即可一鍵交付應用并進行更新。

如果再對這個定義里面的關鍵內容做下提取，其核心包括：

• 無須編碼或少量編碼
• 可視化和可配置化，通過組裝或配置構建應用

在這兩點之外，還有一個關于過程支撐層面的，即整個開發完成的應用上線或交付過程應該足夠簡單和自動化，包括上面提到的可以實現配置立即生效，實現一鍵交付等。

當前有很多提供低代碼開發平臺的服務商，各家的方案或整體架構雖然有差異，但是本質的內容基本還是一致，即一切皆是可配置，可建模的。

可以設想下開發一個簡單功能的過程，基本也就是數據庫表設計，前端界面設計，編寫邏輯層代碼和接口實現業務規則，掛接流程引擎實現流程，配置功能和數據權限等。

所以任何一個低代碼開發平臺都需要圍繞這個核心去抽象和建模，找出共性的和業務無關的東西進行技術沉淀，即我們常說的。

完全標準的東西直接標準化

非標準但是同樣場景的東西，通過抽象差異來實現參數化配置

大家可以看到，實際我們LCDP平臺的構建基本就是圍繞上面思路展開。那么一個LCDP平臺的核心要素究竟是啥，具體我重新畫了一張圖來說明。

即LCDP平臺的核心包括了上圖中的數據建模，表單建模，流程建模，權限建模，報表建模和規則建模幾個關鍵部分的內容，通過這些建模組件，包括這些組件之間本身的協同來完成一個完整業務系統和功能的構建。

對象建模驅動

一個好的低代碼開發平臺應該是以對象建模為驅動的，這個有點類似于很早以前談到的MDA模型驅動架構的思想。即首先進行對象建模，這里的對象更偏業務對象或領域對象，一個對象本身可以對應到多張數據庫表，可以是層次結構表，也可以是管理結構表。

對象建模完成，朝前可以暴露領域服務能力接口，朝后可以對接數據庫進行持久化。當暴露領域服務能力接口的時候更加容易實現前端和后端邏輯之間的徹底分離和解耦，同時在領域服務實現內部也更容易進行相關的事務控制。

在采用對象建模后，實際在后端模型和前端界面之間增加了一個對象服務層，對象服務通過API接口方式對外提供，這個和SOA分層應用構建思路是吻合的。

在對象建模完成后，對象本身朝下可以生成數據庫表，朝上可以發布API接口服務。而對于表單建模不再直接和數據庫表關聯，而是直接引用對應的API接口服務，在這種情況下對應API接口服務本身也會啟用強服務契約模式進行定義和設計。

當有了獨立的接口層的時候，可以看到要實現上層功能組合或組裝將變得更加容易和方便，即我們可以提供一個類似傳統BPEL流程或服務編排的工具，可視化來進行上層業務的接口組裝和編排。

表單和流程引擎集成

當前市面上很多低代碼平臺本身即是從傳統的BPM軟件或工作流引擎平臺演變而來的，因此流程引擎本身是低代碼平臺底層很重要的一個技術服務能力支持。

對于流程引擎本身和組織模型綁定緊密，以進行相應的細粒度數據權限控制和流程動態權限控制，在這里先不描述具體的組織引擎和流程引擎集成點，而重點分析表單和流程引擎的集成。

表單設計掛接流程

可以先看下最簡單的一個場景，即表單設計和流程設計本身即分離的，可以提前先設計好流程模板，產生一個流程模板ID，然后開始進行表單設計。表單設計完成后，可以選擇一個流程模板ID進行掛接。

在這種場景下表單在提交的時候啟動流程本身也簡單，即：

//GenerateFormID(); 
//Form.Save(); 
//StartWorkflow(Formid，WorkflowTemplateID，Userid）; 

流程審核人填寫擴展信息

如果掛接的流程，所有流程節點的處理人都是簡單的審核通過不通過，填寫要給處理意見，那么上面的處理方式完全滿足。但是更多情況下審核時候需要填寫擴展信息。

比如一個供應商創建申請單，流轉到采購經理處審核的時候，采購經理需要確定供應商的等級，并上傳供應商相關資質信息。供應商等級和供應商資質兩個數據項本身是屬于供應商對象建模的基礎數據項信息，但是不在單據提交的時候維護，而是在審核時維護。

在這種場景下可以看到不能簡單的在表單和流程模板之間建立簡單的關聯和映射，而是應該在表單數據項和流程節點之間進行映射。單獨數據項進行映射粒度太細，因此可以在表單設計的時候引入數據分組，處理數據分組和流程活動節點之間的映射即可。

如上圖，對表單數據進行分組，并建立流程活動節點和表單分組之間的映射和授權關系。整體的表單提交和審批流程就變化為：

• 申請人提交表單信息，只能看到基本信息
• 審批1進入審批，可以看到擴展分組，并對數據維護再提交審批結果
• 審批2進入可以看到三個分組信息，但是只能對擴展分組2進行數據維護，并審核提交結果
• 流程監控中，對于已經執行到的節點，擴展分組信息可見

即以上既實現基于流程的參與人動態權限控制，同時又實現了流程參與人可以在審核流程的過程中對流程表單信息進行維護和填寫。擴展分組信息在維護后仍然保持在基礎的對象數據表，而非流程實例表中，流程實例表僅僅只負責狀態流轉和下一個階段流程參與人計算等。

動態權限+數據權限控制

動態權限簡單來說就是你在處理流程節點過程中有權限查看表單數據，但是處理完成后你的權限即回收。或者說你僅僅能夠看你審核和處理的表單，而不是所有的供應商表單數據。而數據權限則是確認你具體可以看到整個數據對象的哪些數據項，比如前面的分組授權也是常用的控制數據權限的方式。

表單保存和流程啟動流轉解耦

當流程引擎獨立作為技術服務實現的時候，可以看到對于流程啟動，流程流轉等都是調用的API接口服務來完成，那么這個時候就形成了分布式事務場景。

比較好的做法仍然是表單存儲和流程API服務之間需要異步解耦，即對流程流轉觸發請求先寫入到消息中間件，然后在異步訂閱消息隊列數據來啟動流程或流轉節點。

流程規則實現

在整個流程的處理中，還涉及到規則的處理和實現，而對于規則可以理解為兩種。

其一是簡單的判斷規則，比如報銷單金額超過1萬需要流轉到總經理審核；還有一種是負責規則判斷，比如需要進行詳細預算完整性檢查，通過和不通過需要流轉到不同分支。

結合傳統流程引擎實現方式，對于簡單規則可以走參數變量傳遞，而對于復雜規則，則可以考慮直接調用外部API接口服務來實現校驗。

在這里只傳遞需要用作流程判斷的數據項目信息參數到流程執行中，本身也減少資源負荷。對于Param信息的傳遞，一個思路是在流程實例啟動后進行緩存，一個是在每一個流程活動節點執行的時候都重新傳入。個人建議方式是在流程實例啟動的時候進行緩存。

表單和組織權限模型集成

在前面已經談到對象建模要和表單建模分離，即一個對象建模完成后，實際基于這個對象可以構建多個不同的表單模型，還是拿供應商舉例。

一個供應商即使不掛接流程也可以拆分為供應商完整信息維護，供應商銀行信息維護，供應商模糊查詢，供應商資質信息查詢，特定供應商信息查詢等不同的表單功能，但是這些表單功能都對應同一個對象模型。表單設計完成后形成的是表單功能。一個表單設計完成后，可以掛接到具體的功能菜單上，同時也可以和某個具體的操作按鈕或事件綁定。簡單來說就是表單本身可能是存在入口參數的。

一個供應商查詢功能表單，查詢結果是列表，可以點列表里面的詳細信息鏈接，這個時候應該調整到特定供應商查看界面，那么供應商ID就是重要的傳入參數。

可以看到整體權限控制思路仍然是基于角色+資源的訪問授權。

一個表單掛接到菜單資源，菜單可以授權給用戶組或角色。同樣，對應表單設計中的數據項或數據分組也可以定義為需要細粒度控制的資源對象，在資源定義完成后講資源對象授權到具體的用戶組或角色，包括表單中的按鈕等都可以采用該思路進行。

即在表單建模完成后，我們需要對建模完成的表單抽象資源對象，資源對象可以是一個獨立的數據項，也可以是數據分組或者按鈕操作。同時再將資源對象和角色或用戶進行綁定。

數據項權限默認設置

一個數據項權限配置最好是既支持默認可見，也支持默認不可見。比如采購訂單金額只對采購總結可見，那么這個數據項目默認值則是全不可見，同時將金額定義為資源，授權給采購總監角色。

靜態權限和動態權限重疊

當靜態權限和動態權限重疊時候如何處理？一般來說應該是以動態權限為主，比如靜態權限設置是沒有權限，但是動態權限計算后可操作或可維護，那么該用戶在動態流程執行中對相關信息就具備動態權限控制。流程處理完后權限即消失。

表單和規則引擎

對于低代碼開發平臺來講，實際上我個人并不建議引入比較重的規則引擎，要明白如果真的業務規則很復雜，用規則引擎同樣需要寫大量的腳本代碼才能夠實現，而且這個腳本代碼本身后續更加難以維護。

規則引擎出來這么多年，實際現在很少看到很成熟的在企業信息化領域的應用場景。

對于規則，我們可以分開來看。

一種是基于當前前端已有的表單數據就能夠進行計算和校驗的規則，這類規則一般為參考完整性規則，比如當我在電商平臺訂購商品的時候，選擇了10件商品，都有不同的折扣，但是有些折扣不能同時共享，那么這個時候前端就能夠完成規則計算給出一個最佳折扣和總費用。對于這類規則，表單設計器是需要支持的，最好方式是能夠腳本化，可以自己寫簡單的規則定義腳本并進行處理。

還有一類規則為需要調用后端數據才能夠完成計算的規則。比如在提交報賬單據申請的時候，需要在后臺校驗當前預算是否足夠和滿足，滿足的才能夠提交。

第二類規則實際才是規則引擎可能涉及的場景。

即在第二類場景下整體流程可以理解為

• 在規則模型中定義規則，規則接受輸入并產生輸出
• 表單傳入關鍵param參數到規則引擎
• 規則引起基于param參數從數據庫后臺獲取數據
• 基于提前定義的規則進行規則計算
• 返回規則計算結果給表單前端

f如果規則復雜你會看到規則是不能通過簡單的配置就實現的，仍然需要寫大量的規則腳本代碼。那么在這種情況下更推薦的方式是自己來實現自定義的API接口。

表單設計過程中，對于關鍵事件點都可以調用自定義API接口。

當前快速開發平臺叫低代碼開發是合適的一個叫法，即不要期望所有復雜地方都能夠配置出來，特別是復雜規則實現。最好的方式就是復雜規則仍然是自己寫代碼實現接口，然后在表單建模和流程建模的時候能夠調用自己寫好的API接口方法。

事件是一個軟件開發里面標準概念，點擊按鈕，下拉選擇框，焦點移出等都可以觸發事件。對于事件觸發后在無規則的情況下就會調用表單自己的處理邏輯。

比如保存按鈕，事件觸發后就調用表單保存操作對數據進行保存。但是實際上你會看到在保存前你可能需要進行業務規則和邏輯處理，在保存后你可能觸發其它關聯操作。

//Form.SaveBefore(); 
//Form.Save 
//Form.SaveAfter(); 

當前在保存前你還可能調用多個API接口進行多個校驗。

這個時候就出現另外一個關鍵點，即不僅僅是支持事件前后調用外部API接口，還需要支持對API接口進行簡單的編排。

實際上你可以看到，對于一個完整的低代碼開發平臺，面對各種復雜業務場景的時候，這種開放的編排能力是必須的。這種編排思路實際和SOA上的服務組合或流程編排思路是一致的。

服務組合編排

還是以電商產品購買為例，在進行訂單提交的時候，如果需要同時處理三個動作。即調用訂單對象的保存操作，調用庫存對象的庫存扣減，調用配送單對象的配送單自動創建。

在這種場景下你可以看到如果沒有服務組合和編排能力是很難實現的。

即將對象建模暴露的接口能力進一步進行可視化的組裝和編排，形成組合服務能力再暴露給表單設計中使用。

一個好的低代碼開發平臺參考SOA分層架構思想和領域建模思想是必要的，即對象建模設計完成后暴露API接口服務能力，前臺的表單設計是和API接口服務層進行交互。這種設計方式方便后續進行服務能力編排的擴展。

即使前期沒有可視化服務編排能，我們也可以自定義API接口服務能力進行接入。