在一些“業(yè)務(wù)邏輯復(fù)雜且非常易變，但單業(yè)務(wù)功能的邏輯復(fù)雜度不是很高”的場景下，低碼平臺是這類業(yè)務(wù)系統(tǒng)的提效利器，如審批流管理、營銷活動搭建、常規(guī)H5建站工具等。本文站在活動工廠的角度，對低碼建設(shè)進行了分析，一起來看一下吧。

(資料圖片僅供參考)

這兩年低碼的概念始終很火，看上去像是解決代碼開發(fā)的銀彈，但是低碼并不是所有的場景都是適用的，在一些“業(yè)務(wù)邏輯復(fù)雜且非常易變，但單業(yè)務(wù)功能點的邏輯復(fù)雜度不是很高”的場景下，低碼平臺是這類業(yè)務(wù)系統(tǒng)提效的提效利器，比如說審批流管理、營銷活動搭建、常規(guī)H5建站工具、報名簽到功能等等，業(yè)界也有相當(dāng)多的低碼平臺布局。

先看一下低碼的概念，通常是指一種可視化的開發(fā)方法，用較少的代碼、較快的速度來交付應(yīng)用程序，將程序員不想開發(fā)的代碼做到自動化稱之為低代碼，相似的概念還有“無代碼”，也是一種開發(fā)方法，通常是面向非技術(shù)性員工，不需要寫任何一行代碼來構(gòu)建應(yīng)用程序，所以兩者的差異主要是面向人群的不同和對于代碼忍受的力度。拿拖拽式H5建站平臺來說，拖拽式H5建站平臺本質(zhì)上屬于無碼、而基于H5建站的DSL或者規(guī)則引擎進行編程則屬于低碼、H5建站平臺本身的開發(fā)屬于純代碼開發(fā)。

這些概念的沒必要區(qū)分的那么清楚，大家通常說的“低碼” 大多是泛指“無碼” + “低碼”。

本文主要站在活動工廠的角度來看低碼建設(shè)，其中的低碼平臺的建設(shè)思路是互通的，都是大致類似的思想和架構(gòu)方案，其他業(yè)務(wù)場景適當(dāng)微調(diào)適配就可以啦，個人認為在大業(yè)務(wù)領(lǐng)域下的低碼建設(shè)是最高效的，適用于所有業(yè)務(wù)并且純粹的低碼是不存在的（僅僅個人觀點）。

一、收益分析

前面提到做低碼平臺多么多么有效，到底是如何提效的下面來看下：

1. 平臺定位分析

我們做一個系統(tǒng)，通常來說參與方有四個：

功能的直接使用方（用戶、銷售、運營、三方系統(tǒng)）；功能的運維方（負責(zé)功能的后臺運營比如運營、產(chǎn)品）；功能的構(gòu)建方（研發(fā)）；機器成本等基礎(chǔ)資源運維方。

2. 收益分析

我們的系統(tǒng)的成本主要是研發(fā)構(gòu)建成本、功能運維成本、資源成本，首先低碼手段能夠直接的降低功能的開發(fā)成本、功能優(yōu)化迭代速度快之后功能運營成本也間接得到優(yōu)化，由于低碼是基于Faas思想做的資源隔離部署，一定程度上也節(jié)省了機器資源。

當(dāng)節(jié)省后的開發(fā)成本能蓋過新增低碼平臺的工作量時，整體收益無疑是正向的。

純代碼、無碼化、低碼化三種方式的開發(fā)迭代成本差異，拿做只有一個玩法的活動來看：

二、代碼切入點

我們通常的開發(fā)流程在業(yè)務(wù)提需之后，我們首先是領(lǐng)域建模，然后是服務(wù)構(gòu)建，最后發(fā)布運行（B、C兩端），我們低碼的環(huán)節(jié)是針對代碼建模、服務(wù)構(gòu)建兩部分進行的，每個模型的代碼建模環(huán)節(jié)主要有職責(zé)的定義、屬性定義、邏輯開發(fā)三部分，服務(wù)構(gòu)建過程主要有模型直接串聯(lián)關(guān)系、組合關(guān)系以及關(guān)系的決策邏輯的開發(fā)。

三、低碼——組裝式架構(gòu)設(shè)計思路

對于這部分的低碼化，首先從粗粒度不斷向下拆解，我們一個領(lǐng)域某場景下的業(yè)務(wù)可以分拆為若干的功能，功能由若干的業(yè)務(wù)能力單元組成，業(yè)務(wù)能力單于由若干的原子能力構(gòu)成，如果想進行低碼的設(shè)計，最直觀的思路就是拼圖或者搭積木的形式來構(gòu)建，然后過程中進行一些業(yè)務(wù)邏輯的填充。

所以整體的思路就是上述拆解的逆過程：

上述就是一種經(jīng)典的Faas+組裝式架構(gòu)的設(shè)計方法，不僅是低碼的落地可以如此使用（利用低碼手段進行組裝），我們對于日常一些復(fù)雜業(yè)務(wù)的架構(gòu)也可以是同樣的思路，面向散落的零件進行組裝式開發(fā)（只不過是純粹的代碼復(fù)用思路或者服務(wù)復(fù)用思路而已），常見的展示型web服務(wù)、密集計算類服務(wù)都是這樣的處理思路。

易變邏輯的處理：

對于一些其中非常易變的業(yè)務(wù)邏輯，用低碼去做雖然成本小了，但是面對巨大的變更依舊是不合適的，這時候這部分仍然需要從無碼邏輯中抽離，在規(guī)則引擎或者DSL之上建設(shè)動態(tài)邏輯注入，以此應(yīng)對變化。

四、整體邏輯架構(gòu)

根據(jù)上述思路，整體進行歸納抽象后整體的邏輯架構(gòu)差不多長這樣：

藍色部分為核心的低碼能力部分：網(wǎng)關(guān)負責(zé)分配我們服務(wù)功能點對應(yīng)的URI；中間層集成核心的對象建模、服務(wù)定義、流程編排、既定復(fù)雜領(lǐng)域等核心功能；其中最底層為低碼驅(qū)動引擎：低碼解析引擎（驅(qū)動）、基礎(chǔ)函數(shù)的注冊發(fā)現(xiàn)能力（地址）、負責(zé)服務(wù)串聯(lián)編排的業(yè)務(wù)事件總線（控制）、對于事件發(fā)生時對于交互維護的總線（數(shù)據(jù)），感覺有點像CPU + 三大總線結(jié)構(gòu)，哈哈哈哈。

墨綠色部分為低碼工具庫：首先是當(dāng)前平臺集成好的函數(shù)庫；然后是對于外部函數(shù)或者服務(wù)的接入；最右是低碼依賴的一些基礎(chǔ)能力：上下文存儲、自定義存儲、表達式引擎、代碼生成器等等；常用問題的解決方案，如果大家興致比較高的話，可以單獨溝通或者單獨描述。

運行視圖：

五、看個demo

以上述整體的邏輯架構(gòu)所呈現(xiàn)的功能來看一下如何搭建一個活動模版，如何落地一個活動。

1. 確定玩法

首先本次demo的活動中有盲盒抽獎、任務(wù)列表、兌換、金豆代幣、養(yǎng)成小游戲、簽到等若干玩法，整個活動中的大實體基本有這么幾個，我們就以這幾個模型進行功能設(shè)計，確定模型之后再確定玩法之間的關(guān)聯(lián)關(guān)系設(shè)計即可。

2. 落地金豆玩法

首先金豆本質(zhì)上就是個代幣，也就是基礎(chǔ)的流水賬模型，我們直接使用基礎(chǔ)函數(shù)庫中的賬務(wù)模型作為單元能力，然后并不需要做額外的邏輯處理，只需要給這個服務(wù)賦予一點業(yè)務(wù)屬性（名稱等等），然后選擇我們用的到的基礎(chǔ)函數(shù)，便可以直接構(gòu)建出金豆增加、金豆扣減、明細查詢、余額查詢等能力。最后完成api的映射實現(xiàn)“金豆”能力暴露即可。

3. 落地簽到玩法

簽到相對麻煩些，業(yè)務(wù)屬性相對較重，沒有現(xiàn)成的模型作為輸入支撐，此時我們需要做基礎(chǔ)函數(shù)單元的“組合拼裝”。

確定簽到配置的元數(shù)據(jù)，實體中有活動id、各周期限制等等；確定簽到實體的元數(shù)據(jù)，實體中有用戶ID、活動ID、計數(shù)周期、當(dāng)前計數(shù)等等；確定我們要實現(xiàn)的輸入能力：簽到、補簽、增加簽到機會、增減補簽機會；確定我們要實現(xiàn)的輸出能力：簽到成功、補簽成功、連續(xù)簽到、簽到記錄；根據(jù)我們要實現(xiàn)的功能確定用到的基礎(chǔ)能力：計數(shù)、周期計算、機會能力、限制能力等等；對于基礎(chǔ)能力進行組裝拼接，這里可以有3種模式，我們可以通過拖拽的形式將基礎(chǔ)函數(shù)進行組合進行輸入輸出的關(guān)聯(lián)、各種if-else的處理；我們也可以直接編寫代碼實現(xiàn)邏輯處理；也可通過編寫系統(tǒng)內(nèi)感知的DSL簡化拼接邏輯。實現(xiàn)輸入輸出的api映射暴露至此就完成了一個簽到玩法的搭建。

4. 落地盲盒玩法

盲盒抽獎的玩法組裝拼接也是類似的，只不過用到的基礎(chǔ)函數(shù)不同。

確定配置的元數(shù)據(jù)，比如活動、獎池、獎品，及其中的對應(yīng)字段；確定業(yè)務(wù)實體的元數(shù)據(jù)，比如用戶當(dāng)前狀態(tài)、用戶中獎記錄，及其中的對應(yīng)屬性；確定服務(wù)的輸入：開盲盒、增加盲盒機會；確定服務(wù)的輸出：盲盒獎品列表、開盲盒記錄；確定對應(yīng)服務(wù)邏輯中的基礎(chǔ)函數(shù)：機會、周期、限制、概率、庫存等等；根據(jù)功能邏輯進行基礎(chǔ)能力的編排，同樣是三種方式，比如拖拽完成抽獎功能，當(dāng)前周期、機會-1、限制消耗+1、獎池選擇、概率選擇、計數(shù)統(tǒng)計；完成對應(yīng)服務(wù)的API對應(yīng)。

5. 玩法間的編排

當(dāng)我們完成玩法（業(yè)務(wù)能力單元）的定義之后，我們就需要對于整體邏輯進行編排，把這些相對完整的工具組合成一場真正的活動。此時我們需要做的是對于玩法各種輸入輸出的關(guān)聯(lián)，并對于關(guān)聯(lián)關(guān)系進行動態(tài)決策（場景、身份等）。

比如說：

任務(wù)完成增加盲盒機會簽到每連續(xù)十天上報周期任務(wù)完成每日簽到增加金豆消耗金豆兌換盲盒機會某些高價值任務(wù)完成增加盲盒機會簽到完成增加盲盒機會

這塊的具體設(shè)計可以參照之前《活動流程編排》一文。

6. 前后端的配合

整體看下來我們需要一個這樣的低碼平臺“開發(fā)環(huán)境”來構(gòu)建我們的低碼產(chǎn)物，在編輯器里可以完成基礎(chǔ)業(yè)務(wù)單元的組裝工作、業(yè)務(wù)單元之間的拼接工作等等。

完成整體活動或者說我們業(yè)務(wù)功能的搭建之后，接下來的工作是對于我們暴露出來的能力進行適配搭建前端界面，其中包括B端運營界面、C端用戶使用界面。對于B端運營操作界面，由于樣式上要求并沒有那么高，可以定義一個前端模版對于低碼過程中生成的元數(shù)據(jù)及API接口進行直接渲染。對于C端用戶使用界面，可以基于

進行頁面功能的構(gòu)建，通過前端的低碼應(yīng)用進行頁面的拖拽搭建。

六、代碼建設(shè)后的收益

整體看下來低成本低碼平臺建設(shè)后，對我們的收益是很大的，整體的思路也是切實可行的，整個建設(shè)過程對于業(yè)務(wù)收益是比較大的，比如：

沉淀的基礎(chǔ)能力，除低碼平臺可以使用外，日常純代碼開發(fā)也是可以直接用的，也為無碼功能增加了一件可復(fù)用能力。業(yè)務(wù)單元能力，由于迭代效率較高，功能豐富度、優(yōu)化程度要更好，并且很多時候可直接復(fù)用。業(yè)務(wù)功能，能力在使用過程不斷沉淀，可以直接復(fù)用，由于可以直接拖拽編排，整體的開發(fā)成本是直線下降的。對于功能來說，迭代效率更高。

整體是好的，但是在低碼平臺的建設(shè)啟動及過程中需要注意的是：

1）術(shù)業(yè)有專攻，不要貪大求全，在適合且某個特定的大業(yè)務(wù)領(lǐng)域下建設(shè)才是合理的。

2）函數(shù)庫的積累是一個循序漸進的過程，根據(jù)訴求逐步沉淀基礎(chǔ)函數(shù)才是王道。

3）低碼、無碼、純代碼并不互斥，界限也相對模糊，他們只是適用于不同場景，受用不同的迭代效率和使用人群，很多時候一次性單功能純代碼開發(fā)效率最高（上低碼走彎路）、無代碼就能滿足使用人群（適用人群是運營、研發(fā)無訴求），功能性增迭代要求非常快、倒排需求較多、功能相對類似、開發(fā)資源相對匱乏的場景就很適合低碼平臺承接。

4）不要過分迷戀DSL，使用既定的工具來解決問題，現(xiàn)有的腳本語言、數(shù)據(jù)架構(gòu)足夠解決問題了。

作者：薄荷點點，“數(shù)據(jù)人創(chuàng)作者聯(lián)盟”成員。

本文由@一個數(shù)據(jù)人的自留地 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。

關(guān)鍵詞： 業(yè)務(wù)開發(fā)銀彈 低代碼平臺建設(shè)（低碼精華篇）