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

低程式碼平臺概述

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

低程式碼開發平臺（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介面服務能力進行接入。