導(dǎo)語：本文基于作者虛構(gòu)的“幼兒園健康上報系統(tǒng)”，演示如何用低代碼平臺快速搭建一套應(yīng)用系統(tǒng)，并介紹演示了國內(nèi)外的一些知名aPaaS產(chǎn)品，如Mendix、Outsystems、宜搭、明道云，試圖探討低代碼平臺在產(chǎn)品設(shè)計上的核心本質(zhì)，從而讓大家對低代碼有一個更直觀的理解。
在案例開始之前，我們先聊聊基本概念。
低代碼平臺是繼中臺之后又一個火爆的話題，實際上低代碼本身并不是一個新穎的話題，也不是最近才有的技術(shù)突破和創(chuàng)新，而是存在了十幾二十年的概念。早期的大型管理軟件套件，都有類似于可拖拽式的快速開發(fā)平臺，方便技術(shù)人員不用寫代碼，快速實現(xiàn)某些基礎(chǔ)功能。
低代碼雖然現(xiàn)在習(xí)慣被稱作aPaaS，好像看起來是一種PaaS，顯得和SaaS有密切關(guān)系，但大家需要認(rèn)識到，低代碼開發(fā)平臺并不是因為SaaS才有的概念，而是遠(yuǎn)古時期就已經(jīng)存在了的。
簡單來講，低代碼平臺是一套期望通過拖拽配置，就能實現(xiàn)一套業(yè)務(wù)型軟件系統(tǒng)的開發(fā)平臺，并能無縫的部署上線運行。在這個過程中，當(dāng)然也允許編寫部分代碼，但更重要的是，大量基礎(chǔ)性的編碼工作，都可以被低代碼平臺快速的自動化實現(xiàn)。
低代碼的第一個應(yīng)用場景，是為了幫助成熟的軟件產(chǎn)品，低成本的支持個性化需求，提高開發(fā)速度，甚至做到拓展客群。
例如，很多成熟商業(yè)軟件（包括私有化部署的商業(yè)軟件套件以及SaaS形式的產(chǎn)品），期望通過低代碼平臺的建設(shè)，加強(qiáng)產(chǎn)品擴(kuò)展能力，更好、更快的服務(wù)客戶，以及與 ISV協(xié)作，將產(chǎn)品的目標(biāo)客群拓展到更廣泛的領(lǐng)域和行業(yè)。
在這種情況下，低代碼平臺是低成本高效解決個性化需求終極方案。此時，低代碼的目標(biāo)用戶可能包括工程師、實施顧問。國外的SAP、Oracle、SalesForce，國內(nèi)的用友、金蝶、北森、銷售易等，都有基于自身軟件產(chǎn)品作為基礎(chǔ)核心的低代碼解決方案。
低代碼第二個應(yīng)用場景，是為了幫助甲方企業(yè)，低成本快速搭建全新的應(yīng)用系統(tǒng)，尤其是讓不懂編程的業(yè)務(wù)人員也能自主實現(xiàn)，從而讓企業(yè)以更低的成本享受數(shù)字化技術(shù)賦能業(yè)務(wù)的好處。
實際上，在企業(yè)中大量的應(yīng)用系統(tǒng)都是流程型的，對于邏輯相對簡單，流程鏈條并不復(fù)雜的業(yè)務(wù)場景，找套裝軟件支持大材小用，找外包開發(fā)獨立系統(tǒng)成本又高，那么低代碼平臺可能是一個不錯的選擇。此時，低代碼平臺的目標(biāo)用戶可能包括甲方企業(yè)的業(yè)務(wù)人員，或者IT人員。
國外的OutSystems、Mendix，國內(nèi)的明道云、氚云，都屬于這種情況。需要留意的是，目前國內(nèi)有些做報表平臺、流程引擎的廠商，為了蹭熱度，也都稱自己是低代碼平臺。嚴(yán)格來講，這些廠商提供的產(chǎn)品能力，只是完整低代碼平臺所需具備能力的子集，并不能算低代碼產(chǎn)品。
說了這么多概念，想必大家對低代碼的印象依然比較模糊。接下來，我將通過一個案例，帶著大家去體驗一款低代碼產(chǎn)品的使用。開始之前，還有幾個問題需要和大家強(qiáng)調(diào)：
低代碼只是應(yīng)用系統(tǒng)建設(shè)執(zhí)行層面的工具，而軟件產(chǎn)品設(shè)計中的思考方式和建模過程才是核心，所以我們的案例會花一部分筆墨講述設(shè)計過程，理解后再去學(xué)習(xí)應(yīng)用低代碼平臺就會簡單很多。
我選擇了明道云作為演示產(chǎn)品：第一是因為他比較容易上手；第二是因為明道云的老板任向暉大佬平日喜歡寫公號做分享，我很喜歡他的文章，為了致敬，因此選擇了明道云。需要聲明的是我和明道云沒有任何關(guān)系，甚至試用期間連銷售都沒加過，試用期全程都是我自己對著幫助手冊學(xué)習(xí)操作的。
明道云的學(xué)習(xí)我大概用了一個小時（主要是看幫助文檔），具體上機(jī)實操將案例中的功能實現(xiàn)大概用了兩個小時，整體還是非常好用，容易上手。但這也可能是因為我以前做過研發(fā)，對很多基礎(chǔ)概念都比較容易理解。
好了，接下來，讓我們進(jìn)入案例。
李校長是小豚鼠幼兒園的校長，最近她遇到了一個煩心事，根據(jù)教委統(tǒng)一要求，疫情期間，需要家長每天上報小朋友的健康狀況，學(xué)校統(tǒng)一管理，但是教委又沒有提供統(tǒng)一的技術(shù)支持。
為了實現(xiàn)這個訴求，幼兒園的老師們想盡辦法，比如說用微信群管理，或者在線文檔管理，但都不是很方便，例如無法做實時統(tǒng)計，數(shù)據(jù)容易被誤操作。而如果找一個軟件公司來幫忙做一個小系統(tǒng)，居然要花三四萬元，對于一個幼兒園，這可是一筆不小的開銷。
李校長的侄子小王是一名B端產(chǎn)品經(jīng)理，在閑聊中得知了李校長的難題，心思一動，問道：
小王：姑姑，您說的這事兒，或許我能幫上忙，做一套軟件系統(tǒng)，就可以很好地解決您的問題！
李校長：真的嗎，那太好了，但是我們沒有很多預(yù)算??！
小王：不用花您一分錢，我?guī)湍赓M做，不過我想先了解下您對這個業(yè)務(wù)管理的訴求和期望。
李校長：多謝??！我的訴求很簡單，就是讓家長們每天打卡，如果有健康異常的情況，我能第一時間收到提醒，還能讓老師們?nèi)ジM(jìn)，看看到底啥問題。另外，就是最好能有一些實時報表，讓我看到最新的健康上報情況。
小王：得嘞，我了解了，這事兒交給我了，我?guī)湍O(shè)計一套操作的流程，和支撐的系統(tǒng)，免費給您用！
了解了大概的背景后，小王開始構(gòu)思這套給小豚鼠幼兒園使用的幼兒健康上報系統(tǒng)的設(shè)計方案。
李校長：太棒啦，期待！
小王了解完基本需求后，開始構(gòu)思這套系統(tǒng)該如何設(shè)計。首先整理下這套系統(tǒng)涉及到的利益方，分別如下：
校長：業(yè)務(wù)決策人，系統(tǒng)用戶，希望系統(tǒng)能支撐教委的健康打卡要求，并管理好打卡業(yè)務(wù)。
老師：業(yè)務(wù)執(zhí)行者，系統(tǒng)用戶，需要管理班級和學(xué)生，安排打卡，跟蹤體溫異常的情況。
家長：業(yè)務(wù)參與者，系統(tǒng)用戶，需要完成每日健康上報打卡工作。
雖然業(yè)務(wù)本身過程很簡單，但因為畢竟是一套從無到有搭建的管理系統(tǒng)，有些基礎(chǔ)數(shù)據(jù)準(zhǔn)備工作需要完成。小王思考了一會兒后，繪制出了一份簡明的業(yè)務(wù)流程圖，如下。
可以看到，期望家長能打卡，有些基礎(chǔ)數(shù)據(jù)要先維護(hù)好，根據(jù)常識，需要維護(hù)包括班級信息、學(xué)生信息，而打卡動作是針對學(xué)生的，因此要對學(xué)生關(guān)聯(lián)打卡信息。
另外需求中提到了，如果打卡體溫異常，需要有老師跟進(jìn)，我們考慮生成一個待辦任務(wù)分配給老師，這條待辦任務(wù)關(guān)聯(lián)在異常的打卡記錄上。對業(yè)務(wù)有了以上分析和思考，我們可以繪制出業(yè)務(wù)背后的ER模型圖（領(lǐng)域模型），如下圖。
每名老師可以管理多個班級，每個班級只能有一名老師管理。每個班級可以有多個學(xué)生，每名學(xué)生有多個健康上報記錄（打卡記錄），每個健康上報記錄可以產(chǎn)生一條體溫異常跟蹤記錄。
這些抽象出來的實體，是我們要設(shè)計的這套健康上報系統(tǒng)的核心，因為打卡（健康上報）的過程，實際上就是對這些實體數(shù)據(jù)做增刪改查而已。
接下來，我們基于流程圖，來思考系統(tǒng)落地執(zhí)行的頁面流轉(zhuǎn)圖：
校長管理班級，需要有班級的列表頁、詳情頁（帶有編輯功能）；
老師管理學(xué)生，需要有學(xué)生的列表頁、詳情頁（帶有編輯功能）；
家長上報健康記錄，需要有健康記錄填報頁；
老師查閱健康打卡記錄，需要有健康打卡列表頁；
老師跟進(jìn)體溫異常情況，需要有提問異常任務(wù)的列表頁、詳情頁（帶有編輯功能）。
除了這些頁面級別的操作需求，還有一些業(yè)務(wù)規(guī)則需求，例如：如果健康上報體溫異常，自動生成一條待跟進(jìn)任務(wù)，發(fā)送給該學(xué)生班主任，并推送消息給校長。
總之，我們會發(fā)現(xiàn)，涉及到業(yè)務(wù)運作的功能頁面，主要就是ER實體的列表頁、詳情頁（創(chuàng)建編輯），并且，不同的用戶對不同頁面以及不同的數(shù)據(jù)具有不同的權(quán)限。
經(jīng)過整理分析，我們可以列示出系統(tǒng)涉及到的相關(guān)頁面，以及權(quán)限表如下（此處僅僅是簡單示意，后邊在明道云中我們會展示更加全面詳細(xì)的權(quán)限設(shè)計，包括數(shù)據(jù)權(quán)限的管理設(shè)計方案）：
經(jīng)過以上分析，雖然細(xì)節(jié)還不完備，但我們對“幼兒園健康上報系統(tǒng)”的設(shè)計思路已經(jīng)了然于胸，接下來，我們直接進(jìn)入低代碼平臺的開發(fā)演示環(huán)節(jié)！
首先，我們來到明道云工作臺，點擊“添加應(yīng)用”，創(chuàng)建新應(yīng)用“小豚鼠幼兒園”（已經(jīng)在下圖中）。
接著，我們針對ER模型中的四個實體，分別創(chuàng)建工作表，下圖所示是創(chuàng)建班級實體的工作表編輯頁面。
工作表是明道云的概念，所謂工作表，實際上對應(yīng)著ER建模中的實體，工作表中的相關(guān)控件，定義了實體的字段。例如班級表單中定義了自增長的“班級ID”，字符串類型的字段“班級名稱”，枚舉字段“狀態(tài)”等。
通過表單來呈現(xiàn)出實體，是一種容易讓人理解的設(shè)計方式。而實體背后的本質(zhì)，是所謂的“對象”，以及最終會轉(zhuǎn)移成數(shù)據(jù)庫的表。在有些低代碼平臺中，則通過對象編輯器來定義管理實體，這是一種靈活性更強(qiáng)，但用起來更復(fù)雜的方案，在后文我們還會進(jìn)一步介紹。
不論是表單編輯器，還是對象編輯器，原理是一樣的，管理的都是提煉出的實體。對于非技術(shù)人員來講，表單可能更容易理解接受一些。
在班級表單中，有一個“學(xué)生”的控件，是一種關(guān)聯(lián)記錄組件。因為班級和學(xué)生是一對多關(guān)系，每個班級可以擁有多個學(xué)生，所以在班級表單中，我們允許看到關(guān)聯(lián)在班級下的所有學(xué)生列表，這在B端產(chǎn)品交互中是非常常見的一種設(shè)計形態(tài)。
實體之間所謂一對多、多對多的關(guān)系，體現(xiàn)的是多個表之間的關(guān)聯(lián)，在設(shè)計器中可以輕松地定義班級和學(xué)生的一對多關(guān)系，如下圖：
實現(xiàn)了關(guān)聯(lián)后，表單和表單之間建立了連接，在詳情頁（單條表單數(shù)據(jù)的呈現(xiàn)頁面）展現(xiàn)上，也都會完美的自動完成。例如：下圖是針對某一條班級數(shù)據(jù)的詳情頁（PC版本）：
aPaaS平臺都會自動完成PC版本和移動版本的適配，并且格式都是可調(diào)整的。例如上圖呈現(xiàn)的是PC版的班級詳情頁，下圖則是移動版本：
接下來，我們依次完成“學(xué)生”、“健康上報”、“體溫異常跟蹤”三個實體的表單配置。
下圖中，橫排的“校園管理”、“校長控制臺”，可以理解成我們針對系統(tǒng)配置的一級導(dǎo)航，豎排的四張表單，表示歸屬于某個一級導(dǎo)航，而每個表單在右側(cè)主區(qū)域配置的列表視圖，就是二級導(dǎo)航菜單，如下圖針對班級的表單，定義了“全部”、“生效中的班級”、“已畢業(yè)的班級”、“我的”四個列表視圖，也即“校園管理”一級菜單下的四個二級菜單。
那么，什么是列表視圖呢？
工作表只是定義了實體的具體字段，如何將實體的列表數(shù)據(jù)呈現(xiàn)出來呢？例如，如何將“班級”列表數(shù)據(jù)以不同的展現(xiàn)形式呈現(xiàn)出來呢？這就需要視圖編輯器了！
在視圖編輯器中，可以定義實體對應(yīng)的多條數(shù)據(jù)的列表化呈現(xiàn)，包括列表數(shù)據(jù)默認(rèn)的篩選條件，默認(rèn)的展示字段，默認(rèn)的字段排序，都可以輕松定制，如上圖所示。
在大多數(shù)自研的B端產(chǎn)品中，列表頁（也就是視圖）是最常見的功能頁面，而一般情況下，這類頁面都是硬編碼實現(xiàn)，而非通過類似于視圖編輯器這樣的前端組件實現(xiàn)。在成熟的軟件產(chǎn)品中，已經(jīng)沒有列表頁的概念，都會通過視圖編輯器來處理，這樣就大量的簡化編碼工作。
如下圖，我們針對“班級”表單，定義了四個視圖，分別是“全部”、“生效中班級”、“已畢業(yè)班級”、“我的”，其中截圖呈現(xiàn)的是針對“生效中班級”視圖的默認(rèn)搜索條件配置，可以看到，我們設(shè)置了該視圖默認(rèn)查詢條件，是“狀態(tài)”字段為“教學(xué)中”的所有班級數(shù)據(jù)。
我們先前提到，在“班級”表單中建立了和“學(xué)生”記錄的一對多關(guān)系，在“學(xué)生”表單中，同樣需要有一個字段，關(guān)聯(lián)了“班級”表單的“班級ID”字段，從而完成一對多關(guān)系的定義。
但是，如果我們希望在學(xué)生表單中呈現(xiàn)出所在班級的名稱，以及在學(xué)生視圖中呈現(xiàn)出所在班級的字段，該如何實現(xiàn)呢？
因為在建立一對多關(guān)系式，我們只是定義了ID之間的聯(lián)系，所以，如果想在“學(xué)生”表單中呈現(xiàn)“班級”名稱，必須做一個變量引入的特殊處理，在明道云中，采用了一種叫做“他表字段”的設(shè)計方式，簡單講，就是把關(guān)聯(lián)表的某個字段引入過來，進(jìn)行展現(xiàn)，如下圖：
下邊的紅框，定義了ID之間的關(guān)聯(lián)，上邊的紅框，引入了“班級”表的“名稱”字段，以便在“學(xué)生”表單和視圖中展現(xiàn)。
在其他低代碼產(chǎn)品中，針對這類訴求的解決方案不太相同。
嚴(yán)格來講，表單只是數(shù)據(jù)對象的外化呈現(xiàn)，根據(jù)軟件設(shè)計MVC的分層理念，數(shù)據(jù)定義和前端呈現(xiàn)要分層隔離，對象編輯器嚴(yán)格定義了數(shù)據(jù)實體本身，而如果在表單或視圖中需要做多表連接去呈現(xiàn)其他相關(guān)表的某些字段，則是可視化層面需要解決的問題。
因此，在很多更復(fù)雜一些的低代碼產(chǎn)品中，所有可視化的部分，都是基于頁面編輯器來完成，和底層數(shù)據(jù)定義是互相獨立的兩件事。因為明道云的產(chǎn)品，為了在很大程度上降低用戶的學(xué)習(xí)成本，所以將數(shù)據(jù)底層的對象編輯器，和展示層的表單編輯器融合在一起了。
現(xiàn)在，我們來解決一個棘手的問題。如果我們希望在學(xué)生視圖中，呈現(xiàn)出該學(xué)生的老師姓名，該如何做到呢？通過學(xué)生，可以找到所在班級，但是，負(fù)責(zé)班級的老師是誰呢？如何定義呢？
一種做法，是針對“班級”表單增加一個字段，可以關(guān)聯(lián)老師的賬號，完成老師和班級的關(guān)系映射。在明道云，我們采用了另一種取巧的方式，需要由校長，將每一條班級數(shù)據(jù)的擁有者，修改成具體的老師賬號，如下圖，圖中“王老師”，是一名角色為“老師”的獨立用戶。
通過這個動作，實現(xiàn)了對班級負(fù)責(zé)老師的分配。接下來，再利用前邊提到過的“他表字段”功能，將這個字段值引入其他表單對象中。
如此一來，所有針對某個班級下邊關(guān)聯(lián)的學(xué)生，以及針對學(xué)生關(guān)聯(lián)的健康上報記錄，我們就都可以追溯到所負(fù)責(zé)的老師了，這對下一個需求的實現(xiàn)至關(guān)重要！
我們回憶下，現(xiàn)前有這樣一條需求：如果健康上報體溫異常，自動生成一條待跟進(jìn)任務(wù)，發(fā)送給該學(xué)生班主任，并推送消息給校長。
這個需求該如何實現(xiàn)呢？這就用到了aPaaS平臺中非常核心且重要的流程編輯器功能，可以說流程編輯器是低代碼平臺的靈魂！
將上述需求，進(jìn)一步準(zhǔn)確描述：如果新增或編輯“健康上報”表單數(shù)據(jù)時，其中的“體溫是否正?！弊侄芜x擇了“否”，則自動生成一條狀態(tài)為“待跟進(jìn)”的“體溫異常跟蹤”數(shù)據(jù)，并發(fā)送消息給校長，以及該學(xué)生的老師。
在低代碼平臺中，通過流程編輯器，來實現(xiàn)類似于以上這類帶有自動化觸發(fā)執(zhí)行，以及多表數(shù)據(jù)自動更新的功能。我們來到流程編輯器，創(chuàng)建“異常體溫上報觸發(fā)跟進(jìn)任務(wù)記錄”流程，如下圖：
在圖中，我們設(shè)計了三個流程節(jié)點。
第一個觸發(fā)節(jié)點：定義了當(dāng)“健康上報”表單在新增或更新數(shù)據(jù)時，如果發(fā)現(xiàn)“提問是否正?！弊侄蔚扔凇胺瘛保瑒t往下執(zhí)行。
第二個節(jié)點：當(dāng)發(fā)現(xiàn)體溫異常時，創(chuàng)建一條“體溫異常跟蹤”數(shù)據(jù)，分配給上報記錄學(xué)生的老師。
第三個節(jié)點：發(fā)送應(yīng)用內(nèi)消息給校長和老師，提醒處理，效果如下圖：
由工作流創(chuàng)建的數(shù)據(jù)，創(chuàng)建者字段顯示為工作流，如下圖：
流程編輯器，不是簡單地工作流引擎，我們一般理解的工作流引擎，例如審批流，只是針對單一數(shù)據(jù)對象的多節(jié)點處理。而真正復(fù)雜的流程編輯器BPM，需要在流程中對不同數(shù)據(jù)實體進(jìn)行復(fù)雜處理，這也是很多B端業(yè)務(wù)的核心處理邏輯和過程。
當(dāng)然明道云的流程編輯器功能很多，如下圖，我們不再贅述。
截止現(xiàn)在，還有個核心功能，我們沒有實現(xiàn)，家長如何上報數(shù)據(jù)？
一種辦法，是針對每個家長開通一個賬號，賬號和學(xué)生做關(guān)聯(lián)，家長登錄系統(tǒng)，提交表單時默認(rèn)會提交相關(guān)學(xué)生的“健康上報”記錄。
另一種辦法，是將“健康上報”的表單公開出去，任何人都可以提交，這樣做的好處是不需一個一個維護(hù)家長賬號，壞處是因為系統(tǒng)無法識別提交人和對應(yīng)的兒童，需要提交人手工從學(xué)生清單中選擇學(xué)生，操作比較繁瑣。
如下圖，我們將表單設(shè)置了公開鏈接。
走到這一步，涉及到業(yè)務(wù)流程的核心功能和數(shù)據(jù)表單都開發(fā)完畢了，接下來，我們需要給李校長配置她的管理工作臺，也就是dashboard。通過類似報表引擎的功能，配置出校長的監(jiān)控儀表盤，我們將其放在“校長控制臺”的一級導(dǎo)航下邊，如下圖：
該功能的使用，和經(jīng)典的報表引擎相通，不再贅述。
最后，我們進(jìn)行角色、權(quán)限的設(shè)置。我們設(shè)置了兩個角色，“校長”和“老師”。
B端產(chǎn)品的權(quán)限管理包括兩部分，功能權(quán)限決定了用戶可以訪問哪些菜單，操作哪些按鈕，數(shù)據(jù)權(quán)限決定了用戶可以訪問操作的數(shù)據(jù)集合范圍是什么，一般通過組織機(jī)構(gòu)樹來實現(xiàn)。
下圖是明道云的數(shù)據(jù)權(quán)限配置管理全貌：
可以看到，每個針對每個角色，設(shè)計不同表單視圖的查看、編輯權(quán)限，這是功能權(quán)限。
點擊每個表單最后的設(shè)置按鈕，還可以定義角色針對表單的數(shù)據(jù)權(quán)限，包括是否允許處理所有數(shù)據(jù)，抑或是本人和下屬的數(shù)據(jù)，抑或是本人擁有的數(shù)據(jù)（記得前面案例中我們對班級的“擁有者”進(jìn)行了調(diào)整么），抑或是本人創(chuàng)建的數(shù)據(jù)。
甚至還可以針對具體的字段設(shè)置更精細(xì)化的權(quán)限，如上圖左下角窗口所示意。
完成以上配置，我們的低代碼平臺開發(fā)工作就完畢了，明道云的應(yīng)用系統(tǒng)不需要發(fā)布，配置后立即生效。所有用戶需要注冊明道云賬號來使用配置好的系統(tǒng)。配置完成的應(yīng)用沒有獨立的應(yīng)用程序，通過訪問明道云官網(wǎng)登陸后使用，移動版需要下載明道云APP，登陸后進(jìn)行使用。
最后給大家展示下移動版應(yīng)用的截圖，這些都是自動生成的默認(rèn)設(shè)計，沒有做過調(diào)整。
通過以上例子，相信大家對低代碼平臺的能力已經(jīng)有了一個直觀的感受。
軟件產(chǎn)品設(shè)計的標(biāo)準(zhǔn)結(jié)構(gòu)是MVC模型，即Model（數(shù)據(jù)）、Controller（邏輯）、View（交互界面），低代碼平臺正是通過幾個核心組件，完成了對MVC三層架構(gòu)模型的支撐，對應(yīng)著MVC模型，這三個核心組件分別是數(shù)據(jù)模型設(shè)計器（對應(yīng)Model）、流程設(shè)計器（對應(yīng)Controller）、頁面設(shè)計器（包括了報表設(shè)計器，對應(yīng)View）。
數(shù)據(jù)模型設(shè)計，實現(xiàn)了對底層數(shù)據(jù)對象的定義。我們之前已經(jīng)提到過，不同低代碼平臺，對數(shù)據(jù)對象的定義實現(xiàn)方式并不相同。
數(shù)據(jù)模型設(shè)計器的第一種實現(xiàn)方式，是通過對象編輯器實現(xiàn)數(shù)據(jù)定義。這種方式靈活程度最高，將底層數(shù)據(jù)模型和前端視圖分離，模型聚焦底層，視圖是可視化的呈現(xiàn)。
國外的低代碼平臺Mendix，國內(nèi)的華為云AppCube都采用了這種方式。另外大型商用軟件的低代碼平臺也都采用同樣的設(shè)計，例如SalesForce、紛享銷客等。
下圖是Mendix的對象編輯器，在Mendix中叫做Domain Model（領(lǐng)域模型），實際上領(lǐng)域模型和對象編輯都是屬于面向?qū)ο缶幊痰母拍?。?yán)格來講領(lǐng)域模型和我們之前提到的ER模型并不完全相同，領(lǐng)域模型擁有面向?qū)ο缶幊痰奶卣?，例如泛化、聚合，這些概念ER模型中是沒有的。
另外圖中展現(xiàn)的是Mendix的Windows客戶端版本，除了Web版，Mendix還提供了功能更加強(qiáng)大的Windows客戶端。經(jīng)過簡單體驗，這套客戶端更像是開發(fā)集成編輯器IDE（程序員寫代碼的軟件平臺）。Mendix本身的功能也非常強(qiáng)大，當(dāng)然學(xué)起來也更困難。
國外另一個知名aPaaS產(chǎn)品outsystems也采用了底層對象驅(qū)動的設(shè)計，并且也提供了windows版本的客戶端，安裝后有一個step by step的tutorial，非常驚艷！整套IDE風(fēng)格的產(chǎn)品化設(shè)計，也非常強(qiáng)悍，讓人印象深刻！
華為云的AppCube貌似也是對象編輯器的設(shè)計方式，但因為我的試用申請一直未通過，所以只是通過幫助文檔做了猜測，無法具體體驗，如下圖：
數(shù)據(jù)模型設(shè)計的第二種實現(xiàn)方式，是表單引擎。
對于設(shè)計人員來講，只需要把底層的數(shù)據(jù)對象，理解成Excel的多張獨立的表，每個表通過表單采集數(shù)據(jù)。用戶定義數(shù)據(jù)模型，只需要將表單中的數(shù)據(jù)采集控件定義即可。
例如下圖，是釘釘?shù)囊舜畹谋韱尉庉嬈?，設(shè)計思路和明道云的表單編輯器類似。表單編輯器將數(shù)據(jù)底層設(shè)計和可視化呈現(xiàn)打包在一起，對于非技術(shù)人員更容易理解，但也會喪失前后端分離的靈活性。
定義了底層數(shù)據(jù)后，下一步要定義工作流。對于業(yè)務(wù)型軟件產(chǎn)品，工作流是支撐業(yè)務(wù)運作的核心。業(yè)務(wù)運行的本質(zhì)，就是一個個工作流的執(zhí)行。
淺層次的工作流，是類似于Workflow這樣的審批流，是對單一數(shù)據(jù)對象的處理；深層次的工作流，需要能夠支持多數(shù)據(jù)實體在流程中的自動化處理。后者是低代碼產(chǎn)品的核心功能之一，如果不具備后者的能力，基本上除了問卷表，什么系統(tǒng)都搭不出來。
什么叫多數(shù)據(jù)實體在流程中的自動化處理呢？
比如說銷售型CRM系統(tǒng)，當(dāng)線索的狀態(tài)變?yōu)橐押藢?，就需要自動生成一條待跟進(jìn)的商機(jī)記錄，并將商機(jī)分配給合適的銷售，同時還要生成對應(yīng)的聯(lián)系人記錄和客戶記錄，商機(jī)、聯(lián)系人、客戶的部分字段數(shù)據(jù)來自于線索實體。
這個業(yè)務(wù)邏輯規(guī)則，就需要復(fù)雜的工作流編輯器實現(xiàn)，在這條自動化處理流程中，涉及到了四個實體數(shù)據(jù)的增刪改查（線索、商機(jī)、客戶、聯(lián)系人）。
下圖展示的是Mendix的Windows客戶端版本下的流程編輯器。
下圖展示的是國內(nèi)產(chǎn)品釘釘宜搭的工作流編輯器，感覺似乎過于簡單，只是一個審批流編輯器，也可能是我沒找到完整功能的配置界面？
對于業(yè)務(wù)型軟件產(chǎn)品，主要功能是對數(shù)據(jù)的增刪改查，而涉及到的交互頁面，多數(shù)也都是底層數(shù)據(jù)對象對應(yīng)的列表頁、詳情頁，除此以外，還包括報表、儀表盤，以及其他類型頁面。
對頁面設(shè)計器的設(shè)計理念，明顯體現(xiàn)出了不同低代碼平臺的產(chǎn)品思路，整體來看，可以總結(jié)為兩類形態(tài)。
1）純粹的前端頁面編輯器
包括了報表、列表、視圖、表單，都在這一體化的頁面編輯器中實現(xiàn)。比如Outsystems的頁面編輯器，如下圖：
可以看到，這是一套復(fù)雜的前端交互組件設(shè)計器，包括了類似于數(shù)據(jù)表集合Table Records的集成控件，也包括了表單控件Form，以及其他各類型控件集合，例如復(fù)選框Check Box，單選框Radio Button等等。
在這套編輯器中，操作者可以定義例如列表頁、詳情頁、報表、儀表盤各類型前端頁面。再比如Mendix的頁面編輯器，也是同樣的設(shè)計思路，如下圖：
即便是dashboard，也是在同樣的頁面編輯器實現(xiàn)，如下圖是Mendix的dashbaord的demo：
低代碼平臺的報表設(shè)計器組件，和傳統(tǒng)的報表引擎沒有太大區(qū)別，都是基于底層的數(shù)據(jù)，實現(xiàn)前端可視化輸出，包括表格輸出和圖形輸出。以上是第一種前端交互設(shè)計的產(chǎn)品形態(tài)，可以看出，功能強(qiáng)大、靈活，學(xué)習(xí)成本也比較高。
2）大大簡化了的頁面配置器
將不同類型的頁面，進(jìn)行模板化配置，主要分為以下幾類。
首先：將數(shù)據(jù)對象和表單相結(jié)合，通過定義表單（Form），完成了數(shù)據(jù)對象的定義，同時也構(gòu)建出了詳情頁；
其次：通過視圖編輯器這類組件，定義了針對數(shù)據(jù)對象的列表頁；
最后：通過單獨的dashboard配置器，完成類似于報表引擎的定義功能。
當(dāng)然，低代碼產(chǎn)品也會提供集成頁面的配置，但功能要比前邊提到的功能弱很多。前文已經(jīng)大量描述了明道云的視圖編輯器，不再贅述。
下圖是宜搭的頁面編輯器，展示了對某個系統(tǒng)首頁的編輯。相對明道云，宜搭的頁面編輯器更復(fù)雜一些，功能也更強(qiáng)大一些。
再例如，下圖是宜搭的報表編輯器：
數(shù)據(jù)模型設(shè)計器、流程設(shè)計器和頁面設(shè)計器，是低代碼平臺的核心，如果你理解軟件設(shè)計的MVC分層架構(gòu)，就很容易理解低代碼平臺的核心產(chǎn)品功能，以及不同的產(chǎn)品思路。當(dāng)然不同低代碼平臺還有更多各具特色的強(qiáng)悍功能，有興趣的讀者可以進(jìn)一步研究。
可以看出，不同的低代碼平臺，設(shè)計思路并不相同。
產(chǎn)品的易用性和產(chǎn)品的靈活性之間存在平衡和取舍。例如，對于數(shù)據(jù)底層，究竟選擇表單驅(qū)動的設(shè)計，還是領(lǐng)域驅(qū)動的設(shè)計？這兩者區(qū)別非常大，后者對于非技術(shù)人員，基本不可用，而前者雖然易于學(xué)習(xí)理解，但功能確實也要弱化很多。
因此，低代碼平臺要明確目標(biāo)用戶群體，究竟是給ISV或IT團(tuán)隊使用的專業(yè)開發(fā)輔助工具，還是給非技術(shù)人員使用的強(qiáng)化版提效工具？前者更像是IDE的超級插件包，后者更像是Excel + VBA的超強(qiáng)易用版。
對于B端產(chǎn)品經(jīng)理來講，體驗下類似于明道云這樣的低代碼產(chǎn)品，對理解軟件設(shè)計很有益處，不論是表單，還是流程，還是權(quán)限管理，所有核心的產(chǎn)品設(shè)計問題都會涉及到，并且能夠加深理解。
另外，萬一業(yè)務(wù)有個大型需求，研發(fā)沒排期，你3個小時就用aPaaS配置出來了，年度CEO特別獎不給你給誰呢！
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理
題圖來自 Unsplash，基于 CC0 協(xié)議
聯(lián)系客服
