如何理解低代碼開(kāi)發(fā)平臺(tái)核心組件集成和協(xié)同

這篇文章主要講解了“如何理解低代碼開(kāi)發(fā)平臺(tái)核心組件集成和協(xié)同”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“如何理解低代碼開(kāi)發(fā)平臺(tái)核心組件集成和協(xié)同”吧！

低代碼平臺(tái)概述

對(duì)于低代碼開(kāi)發(fā)平臺(tái)，百度詞條有一個(gè)基礎(chǔ)定義，如下：

低代碼開(kāi)發(fā)平臺(tái)（LCDP）是無(wú)需編碼（0代碼）或通過(guò)少量代碼就可以快速生成應(yīng)用程序的開(kāi)發(fā)平臺(tái)。通過(guò)可視化進(jìn)行應(yīng)用程序開(kāi)發(fā)的方法（參考可視編程語(yǔ)言），使具有不同經(jīng)驗(yàn)水平的開(kāi)發(fā)人員可以通過(guò)圖形化的用戶界面，使用拖拽組件和模型驅(qū)動(dòng)的邏輯來(lái)創(chuàng)建網(wǎng)頁(yè)和移動(dòng)應(yīng)用程序。低代碼開(kāi)發(fā)平臺(tái)在完成業(yè)務(wù)邏輯、功能構(gòu)建后，即可一鍵交付應(yīng)用并進(jìn)行更新。

如果再對(duì)這個(gè)定義里面的關(guān)鍵內(nèi)容做下提取，其核心包括：

• 無(wú)須編碼或少量編碼

• 可視化和可配置化，通過(guò)組裝或配置構(gòu)建應(yīng)用

在這兩點(diǎn)之外，還有一個(gè)關(guān)于過(guò)程支撐層面的，即整個(gè)開(kāi)發(fā)完成的應(yīng)用上線或交付過(guò)程應(yīng)該足夠簡(jiǎn)單和自動(dòng)化，包括上面提到的可以實(shí)現(xiàn)配置立即生效，實(shí)現(xiàn)一鍵交付等。

當(dāng)前有很多提供低代碼開(kāi)發(fā)平臺(tái)的服務(wù)商，各家的方案或整體架構(gòu)雖然有差異，但是本質(zhì)的內(nèi)容基本還是一致，即一切皆是可配置，可建模的。

可以設(shè)想下開(kāi)發(fā)一個(gè)簡(jiǎn)單功能的過(guò)程，基本也就是數(shù)據(jù)庫(kù)表設(shè)計(jì)，前端界面設(shè)計(jì)，編寫(xiě)邏輯層代碼和接口實(shí)現(xiàn)業(yè)務(wù)規(guī)則，掛接流程引擎實(shí)現(xiàn)流程，配置功能和數(shù)據(jù)權(quán)限等。

所以任何一個(gè)低代碼開(kāi)發(fā)平臺(tái)都需要圍繞這個(gè)核心去抽象和建模，找出共性的和業(yè)務(wù)無(wú)關(guān)的東西進(jìn)行技術(shù)沉淀，即我們常說(shuō)的。

完全標(biāo)準(zhǔn)的東西直接標(biāo)準(zhǔn)化

非標(biāo)準(zhǔn)但是同樣場(chǎng)景的東西，通過(guò)抽象差異來(lái)實(shí)現(xiàn)參數(shù)化配置

大家可以看到，實(shí)際我們LCDP平臺(tái)的構(gòu)建基本就是圍繞上面思路展開(kāi)。那么一個(gè)LCDP平臺(tái)的核心要素究竟是啥，具體我重新畫(huà)了一張圖來(lái)說(shuō)明。

即LCDP平臺(tái)的核心包括了上圖中的數(shù)據(jù)建模，表單建模，流程建模，權(quán)限建模，報(bào)表建模和規(guī)則建模幾個(gè)關(guān)鍵部分的內(nèi)容，通過(guò)這些建模組件，包括這些組件之間本身的協(xié)同來(lái)完成一個(gè)完整業(yè)務(wù)系統(tǒng)和功能的構(gòu)建。

對(duì)象建模驅(qū)動(dòng)

一個(gè)好的低代碼開(kāi)發(fā)平臺(tái)應(yīng)該是以對(duì)象建模為驅(qū)動(dòng)的，這個(gè)有點(diǎn)類(lèi)似于很早以前談到的MDA模型驅(qū)動(dòng)架構(gòu)的思想。即首先進(jìn)行對(duì)象建模，這里的對(duì)象更偏業(yè)務(wù)對(duì)象或領(lǐng)域?qū)ο?，一個(gè)對(duì)象本身可以對(duì)應(yīng)到多張數(shù)據(jù)庫(kù)表，可以是層次結(jié)構(gòu)表，也可以是管理結(jié)構(gòu)表。

對(duì)象建模完成，朝前可以暴露領(lǐng)域服務(wù)能力接口，朝后可以對(duì)接數(shù)據(jù)庫(kù)進(jìn)行持久化。當(dāng)暴露領(lǐng)域服務(wù)能力接口的時(shí)候更加容易實(shí)現(xiàn)前端和后端邏輯之間的徹底分離和解耦，同時(shí)在領(lǐng)域服務(wù)實(shí)現(xiàn)內(nèi)部也更容易進(jìn)行相關(guān)的事務(wù)控制。

在采用對(duì)象建模后，實(shí)際在后端模型和前端界面之間增加了一個(gè)對(duì)象服務(wù)層，對(duì)象服務(wù)通過(guò)API接口方式對(duì)外提供，這個(gè)和SOA分層應(yīng)用構(gòu)建思路是吻合的。

在對(duì)象建模完成后，對(duì)象本身朝下可以生成數(shù)據(jù)庫(kù)表，朝上可以發(fā)布API接口服務(wù)。而對(duì)于表單建模不再直接和數(shù)據(jù)庫(kù)表關(guān)聯(lián)，而是直接引用對(duì)應(yīng)的API接口服務(wù)，在這種情況下對(duì)應(yīng)API接口服務(wù)本身也會(huì)啟用強(qiáng)服務(wù)契約模式進(jìn)行定義和設(shè)計(jì)。

當(dāng)有了獨(dú)立的接口層的時(shí)候，可以看到要實(shí)現(xiàn)上層功能組合或組裝將變得更加容易和方便，即我們可以提供一個(gè)類(lèi)似傳統(tǒng)BPEL流程或服務(wù)編排的工具，可視化來(lái)進(jìn)行上層業(yè)務(wù)的接口組裝和編排。

表單和流程引擎集成

當(dāng)前市面上很多低代碼平臺(tái)本身即是從傳統(tǒng)的BPM軟件或工作流引擎平臺(tái)演變而來(lái)的，因此流程引擎本身是低代碼平臺(tái)底層很重要的一個(gè)技術(shù)服務(wù)能力支持。

對(duì)于流程引擎本身和組織模型綁定緊密，以進(jìn)行相應(yīng)的細(xì)粒度數(shù)據(jù)權(quán)限控制和流程動(dòng)態(tài)權(quán)限控制，在這里先不描述具體的組織引擎和流程引擎集成點(diǎn)，而重點(diǎn)分析表單和流程引擎的集成。

表單設(shè)計(jì)掛接流程

可以先看下最簡(jiǎn)單的一個(gè)場(chǎng)景，即表單設(shè)計(jì)和流程設(shè)計(jì)本身即分離的，可以提前先設(shè)計(jì)好流程模板，產(chǎn)生一個(gè)流程模板ID，然后開(kāi)始進(jìn)行表單設(shè)計(jì)。表單設(shè)計(jì)完成后，可以選擇一個(gè)流程模板ID進(jìn)行掛接。

在這種場(chǎng)景下表單在提交的時(shí)候啟動(dòng)流程本身也簡(jiǎn)單，即：

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

流程審核人填寫(xiě)擴(kuò)展信息

如果掛接的流程，所有流程節(jié)點(diǎn)的處理人都是簡(jiǎn)單的審核通過(guò)不通過(guò)，填寫(xiě)要給處理意見(jiàn)，那么上面的處理方式完全滿足。但是更多情況下審核時(shí)候需要填寫(xiě)擴(kuò)展信息。

比如一個(gè)供應(yīng)商創(chuàng)建申請(qǐng)單，流轉(zhuǎn)到采購(gòu)經(jīng)理處審核的時(shí)候，采購(gòu)經(jīng)理需要確定供應(yīng)商的等級(jí)，并上傳供應(yīng)商相關(guān)資質(zhì)信息。供應(yīng)商等級(jí)和供應(yīng)商資質(zhì)兩個(gè)數(shù)據(jù)項(xiàng)本身是屬于供應(yīng)商對(duì)象建模的基礎(chǔ)數(shù)據(jù)項(xiàng)信息，但是不在單據(jù)提交的時(shí)候維護(hù)，而是在審核時(shí)維護(hù)。

在這種場(chǎng)景下可以看到不能簡(jiǎn)單的在表單和流程模板之間建立簡(jiǎn)單的關(guān)聯(lián)和映射，而是應(yīng)該在表單數(shù)據(jù)項(xiàng)和流程節(jié)點(diǎn)之間進(jìn)行映射。單獨(dú)數(shù)據(jù)項(xiàng)進(jìn)行映射粒度太細(xì)，因此可以在表單設(shè)計(jì)的時(shí)候引入數(shù)據(jù)分組，處理數(shù)據(jù)分組和流程活動(dòng)節(jié)點(diǎn)之間的映射即可。

如上圖，對(duì)表單數(shù)據(jù)進(jìn)行分組，并建立流程活動(dòng)節(jié)點(diǎn)和表單分組之間的映射和授權(quán)關(guān)系。整體的表單提交和審批流程就變化為：

• 申請(qǐng)人提交表單信息，只能看到基本信息

• 審批1進(jìn)入審批，可以看到擴(kuò)展分組，并對(duì)數(shù)據(jù)維護(hù)再提交審批結(jié)果

• 審批2進(jìn)入可以看到三個(gè)分組信息，但是只能對(duì)擴(kuò)展分組2進(jìn)行數(shù)據(jù)維護(hù)，并審核提交結(jié)果

• 流程監(jiān)控中，對(duì)于已經(jīng)執(zhí)行到的節(jié)點(diǎn)，擴(kuò)展分組信息可見(jiàn)

即以上既實(shí)現(xiàn)基于流程的參與人動(dòng)態(tài)權(quán)限控制，同時(shí)又實(shí)現(xiàn)了流程參與人可以在審核流程的過(guò)程中對(duì)流程表單信息進(jìn)行維護(hù)和填寫(xiě)。擴(kuò)展分組信息在維護(hù)后仍然保持在基礎(chǔ)的對(duì)象數(shù)據(jù)表，而非流程實(shí)例表中，流程實(shí)例表僅僅只負(fù)責(zé)狀態(tài)流轉(zhuǎn)和下一個(gè)階段流程參與人計(jì)算等。

動(dòng)態(tài)權(quán)限+數(shù)據(jù)權(quán)限控制

動(dòng)態(tài)權(quán)限簡(jiǎn)單來(lái)說(shuō)就是你在處理流程節(jié)點(diǎn)過(guò)程中有權(quán)限查看表單數(shù)據(jù)，但是處理完成后你的權(quán)限即回收?；蛘哒f(shuō)你僅僅能夠看你審核和處理的表單，而不是所有的供應(yīng)商表單數(shù)據(jù)。而數(shù)據(jù)權(quán)限則是確認(rèn)你具體可以看到整個(gè)數(shù)據(jù)對(duì)象的哪些數(shù)據(jù)項(xiàng)，比如前面的分組授權(quán)也是常用的控制數(shù)據(jù)權(quán)限的方式。

表單保存和流程啟動(dòng)流轉(zhuǎn)解耦

當(dāng)流程引擎獨(dú)立作為技術(shù)服務(wù)實(shí)現(xiàn)的時(shí)候，可以看到對(duì)于流程啟動(dòng)，流程流轉(zhuǎn)等都是調(diào)用的API接口服務(wù)來(lái)完成，那么這個(gè)時(shí)候就形成了分布式事務(wù)場(chǎng)景。

比較好的做法仍然是表單存儲(chǔ)和流程API服務(wù)之間需要異步解耦，即對(duì)流程流轉(zhuǎn)觸發(fā)請(qǐng)求先寫(xiě)入到消息中間件，然后在異步訂閱消息隊(duì)列數(shù)據(jù)來(lái)啟動(dòng)流程或流轉(zhuǎn)節(jié)點(diǎn)。

流程規(guī)則實(shí)現(xiàn)

在整個(gè)流程的處理中，還涉及到規(guī)則的處理和實(shí)現(xiàn)，而對(duì)于規(guī)則可以理解為兩種。

其一是簡(jiǎn)單的判斷規(guī)則，比如報(bào)銷(xiāo)單金額超過(guò)1萬(wàn)需要流轉(zhuǎn)到總經(jīng)理審核；還有一種是負(fù)責(zé)規(guī)則判斷，比如需要進(jìn)行詳細(xì)預(yù)算完整性檢查，通過(guò)和不通過(guò)需要流轉(zhuǎn)到不同分支。

結(jié)合傳統(tǒng)流程引擎實(shí)現(xiàn)方式，對(duì)于簡(jiǎn)單規(guī)則可以走參數(shù)變量傳遞，而對(duì)于復(fù)雜規(guī)則，則可以考慮直接調(diào)用外部API接口服務(wù)來(lái)實(shí)現(xiàn)校驗(yàn)。

在這里只傳遞需要用作流程判斷的數(shù)據(jù)項(xiàng)目信息參數(shù)到流程執(zhí)行中，本身也減少資源負(fù)荷。對(duì)于Param信息的傳遞，一個(gè)思路是在流程實(shí)例啟動(dòng)后進(jìn)行緩存，一個(gè)是在每一個(gè)流程活動(dòng)節(jié)點(diǎn)執(zhí)行的時(shí)候都重新傳入。個(gè)人建議方式是在流程實(shí)例啟動(dòng)的時(shí)候進(jìn)行緩存。

表單和組織權(quán)限模型集成

在前面已經(jīng)談到對(duì)象建模要和表單建模分離，即一個(gè)對(duì)象建模完成后，實(shí)際基于這個(gè)對(duì)象可以構(gòu)建多個(gè)不同的表單模型，還是拿供應(yīng)商舉例。

一個(gè)供應(yīng)商即使不掛接流程也可以拆分為供應(yīng)商完整信息維護(hù)，供應(yīng)商銀行信息維護(hù)，供應(yīng)商模糊查詢，供應(yīng)商資質(zhì)信息查詢，特定供應(yīng)商信息查詢等不同的表單功能，但是這些表單功能都對(duì)應(yīng)同一個(gè)對(duì)象模型。表單設(shè)計(jì)完成后形成的是表單功能。一個(gè)表單設(shè)計(jì)完成后，可以掛接到具體的功能菜單上，同時(shí)也可以和某個(gè)具體的操作按鈕或事件綁定。簡(jiǎn)單來(lái)說(shuō)就是表單本身可能是存在入口參數(shù)的。

一個(gè)供應(yīng)商查詢功能表單，查詢結(jié)果是列表，可以點(diǎn)列表里面的詳細(xì)信息鏈接，這個(gè)時(shí)候應(yīng)該調(diào)整到特定供應(yīng)商查看界面，那么供應(yīng)商ID就是重要的傳入?yún)?shù)。

可以看到整體權(quán)限控制思路仍然是基于角色+資源的訪問(wèn)授權(quán)。

一個(gè)表單掛接到菜單資源，菜單可以授權(quán)給用戶組或角色。同樣，對(duì)應(yīng)表單設(shè)計(jì)中的數(shù)據(jù)項(xiàng)或數(shù)據(jù)分組也可以定義為需要細(xì)粒度控制的資源對(duì)象，在資源定義完成后講資源對(duì)象授權(quán)到具體的用戶組或角色，包括表單中的按鈕等都可以采用該思路進(jìn)行。

即在表單建模完成后，我們需要對(duì)建模完成的表單抽象資源對(duì)象，資源對(duì)象可以是一個(gè)獨(dú)立的數(shù)據(jù)項(xiàng)，也可以是數(shù)據(jù)分組或者按鈕操作。同時(shí)再將資源對(duì)象和角色或用戶進(jìn)行綁定。

數(shù)據(jù)項(xiàng)權(quán)限默認(rèn)設(shè)置

一個(gè)數(shù)據(jù)項(xiàng)權(quán)限配置最好是既支持默認(rèn)可見(jiàn)，也支持默認(rèn)不可見(jiàn)。比如采購(gòu)訂單金額只對(duì)采購(gòu)總結(jié)可見(jiàn)，那么這個(gè)數(shù)據(jù)項(xiàng)目默認(rèn)值則是全不可見(jiàn)，同時(shí)將金額定義為資源，授權(quán)給采購(gòu)總監(jiān)角色。

靜態(tài)權(quán)限和動(dòng)態(tài)權(quán)限重疊

當(dāng)靜態(tài)權(quán)限和動(dòng)態(tài)權(quán)限重疊時(shí)候如何處理？一般來(lái)說(shuō)應(yīng)該是以動(dòng)態(tài)權(quán)限為主，比如靜態(tài)權(quán)限設(shè)置是沒(méi)有權(quán)限，但是動(dòng)態(tài)權(quán)限計(jì)算后可操作或可維護(hù)，那么該用戶在動(dòng)態(tài)流程執(zhí)行中對(duì)相關(guān)信息就具備動(dòng)態(tài)權(quán)限控制。流程處理完后權(quán)限即消失。

表單和規(guī)則引擎

對(duì)于低代碼開(kāi)發(fā)平臺(tái)來(lái)講，實(shí)際上我個(gè)人并不建議引入比較重的規(guī)則引擎，要明白如果真的業(yè)務(wù)規(guī)則很復(fù)雜，用規(guī)則引擎同樣需要寫(xiě)大量的腳本代碼才能夠?qū)崿F(xiàn)，而且這個(gè)腳本代碼本身后續(xù)更加難以維護(hù)。

規(guī)則引擎出來(lái)這么多年，實(shí)際現(xiàn)在很少看到很成熟的在企業(yè)信息化領(lǐng)域的應(yīng)用場(chǎng)景。

對(duì)于規(guī)則，我們可以分開(kāi)來(lái)看。

一種是基于當(dāng)前前端已有的表單數(shù)據(jù)就能夠進(jìn)行計(jì)算和校驗(yàn)的規(guī)則，這類(lèi)規(guī)則一般為參考完整性規(guī)則，比如當(dāng)我在電商平臺(tái)訂購(gòu)商品的時(shí)候，選擇了10件商品，都有不同的折扣，但是有些折扣不能同時(shí)共享，那么這個(gè)時(shí)候前端就能夠完成規(guī)則計(jì)算給出一個(gè)最佳折扣和總費(fèi)用。對(duì)于這類(lèi)規(guī)則，表單設(shè)計(jì)器是需要支持的，最好方式是能夠腳本化，可以自己寫(xiě)簡(jiǎn)單的規(guī)則定義腳本并進(jìn)行處理。

還有一類(lèi)規(guī)則為需要調(diào)用后端數(shù)據(jù)才能夠完成計(jì)算的規(guī)則。比如在提交報(bào)賬單據(jù)申請(qǐng)的時(shí)候，需要在后臺(tái)校驗(yàn)當(dāng)前預(yù)算是否足夠和滿足，滿足的才能夠提交。

第二類(lèi)規(guī)則實(shí)際才是規(guī)則引擎可能涉及的場(chǎng)景。

即在第二類(lèi)場(chǎng)景下整體流程可以理解為

• 在規(guī)則模型中定義規(guī)則，規(guī)則接受輸入并產(chǎn)生輸出

• 表單傳入關(guān)鍵param參數(shù)到規(guī)則引擎

• 規(guī)則引起基于param參數(shù)從數(shù)據(jù)庫(kù)后臺(tái)獲取數(shù)據(jù)

• 基于提前定義的規(guī)則進(jìn)行規(guī)則計(jì)算

• 返回規(guī)則計(jì)算結(jié)果給表單前端

f如果規(guī)則復(fù)雜你會(huì)看到規(guī)則是不能通過(guò)簡(jiǎn)單的配置就實(shí)現(xiàn)的，仍然需要寫(xiě)大量的規(guī)則腳本代碼。那么在這種情況下更推薦的方式是自己來(lái)實(shí)現(xiàn)自定義的API接口。

表單設(shè)計(jì)過(guò)程中，對(duì)于關(guān)鍵事件點(diǎn)都可以調(diào)用自定義API接口。

當(dāng)前快速開(kāi)發(fā)平臺(tái)叫低代碼開(kāi)發(fā)是合適的一個(gè)叫法，即不要期望所有復(fù)雜地方都能夠配置出來(lái)，特別是復(fù)雜規(guī)則實(shí)現(xiàn)。最好的方式就是復(fù)雜規(guī)則仍然是自己寫(xiě)代碼實(shí)現(xiàn)接口，然后在表單建模和流程建模的時(shí)候能夠調(diào)用自己寫(xiě)好的API接口方法。

事件是一個(gè)軟件開(kāi)發(fā)里面標(biāo)準(zhǔn)概念，點(diǎn)擊按鈕，下拉選擇框，焦點(diǎn)移出等都可以觸發(fā)事件。對(duì)于事件觸發(fā)后在無(wú)規(guī)則的情況下就會(huì)調(diào)用表單自己的處理邏輯。

比如保存按鈕，事件觸發(fā)后就調(diào)用表單保存操作對(duì)數(shù)據(jù)進(jìn)行保存。但是實(shí)際上你會(huì)看到在保存前你可能需要進(jìn)行業(yè)務(wù)規(guī)則和邏輯處理，在保存后你可能觸發(fā)其它關(guān)聯(lián)操作。

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

當(dāng)前在保存前你還可能調(diào)用多個(gè)API接口進(jìn)行多個(gè)校驗(yàn)。

這個(gè)時(shí)候就出現(xiàn)另外一個(gè)關(guān)鍵點(diǎn)，即不僅僅是支持事件前后調(diào)用外部API接口，還需要支持對(duì)API接口進(jìn)行簡(jiǎn)單的編排。

實(shí)際上你可以看到，對(duì)于一個(gè)完整的低代碼開(kāi)發(fā)平臺(tái)，面對(duì)各種復(fù)雜業(yè)務(wù)場(chǎng)景的時(shí)候，這種開(kāi)放的編排能力是必須的。這種編排思路實(shí)際和SOA上的服務(wù)組合或流程編排思路是一致的。

服務(wù)組合編排

還是以電商產(chǎn)品購(gòu)買(mǎi)為例，在進(jìn)行訂單提交的時(shí)候，如果需要同時(shí)處理三個(gè)動(dòng)作。即調(diào)用訂單對(duì)象的保存操作，調(diào)用庫(kù)存對(duì)象的庫(kù)存扣減，調(diào)用配送單對(duì)象的配送單自動(dòng)創(chuàng)建。

在這種場(chǎng)景下你可以看到如果沒(méi)有服務(wù)組合和編排能力是很難實(shí)現(xiàn)的。

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

一個(gè)好的低代碼開(kāi)發(fā)平臺(tái)參考SOA分層架構(gòu)思想和領(lǐng)域建模思想是必要的，即對(duì)象建模設(shè)計(jì)完成后暴露API接口服務(wù)能力，前臺(tái)的表單設(shè)計(jì)是和API接口服務(wù)層進(jìn)行交互。這種設(shè)計(jì)方式方便后續(xù)進(jìn)行服務(wù)能力編排的擴(kuò)展。

即使前期沒(méi)有可視化服務(wù)編排能，我們也可以自定義API接口服務(wù)能力進(jìn)行接入。

感謝各位的閱讀，以上就是“如何理解低代碼開(kāi)發(fā)平臺(tái)核心組件集成和協(xié)同”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)如何理解低代碼開(kāi)發(fā)平臺(tái)核心組件集成和協(xié)同這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！