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

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

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

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

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

一、收益分析

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

1. 平臺(tái)定位分析

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

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

2. 收益分析

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

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

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

二、代碼切入點(diǎn)

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

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

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

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

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

易變邏輯的處理：

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

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

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

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

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

運(yùn)行視圖：

五、看個(gè)demo

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

1. 確定玩法

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

2. 落地金豆玩法

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

3. 落地簽到玩法

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

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

4. 落地盲盒玩法

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

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

5. 玩法間的編排

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

比如說：

1. 任務(wù)完成增加盲盒機(jī)會(huì)
2. 簽到每連續(xù)十天上報(bào)周期任務(wù)完成
3. 每日簽到增加金豆
4. 消耗金豆兌換盲盒機(jī)會(huì)
5. 某些高價(jià)值任務(wù)完成增加盲盒機(jī)會(huì)
6. 簽到完成增加盲盒機(jī)會(huì)

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

6. 前后端的配合

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

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

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

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

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

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

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

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

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

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

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

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

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

該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。