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

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

(資料圖)

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

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

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

一、收益分析

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

1. 平臺定位分析

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

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

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

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

二、代碼切入點

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

三、低碼——組裝式架構設計思路

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

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

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

易變邏輯的處理：

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

四、整體邏輯架構

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

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

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

運行視圖：

五、看個demo

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

1. 確定玩法

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

2. 落地金豆玩法

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

3. 落地簽到玩法

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

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

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

比如說：

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

6. 前后端的配合

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

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

六、代碼建設后的收益

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

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

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

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

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

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

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

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

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

關鍵詞： 基礎函數(shù) 業(yè)務功能 輸入輸出