01 前言

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

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

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

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

02 收益分析

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

2.1平臺定位分析

我們做一個系統，通常來說參與方有四個：

1、功能的直接使用方（用戶、銷售、運營、三方系統）；
2、功能的運維方（負責功能的后臺運營比如運營、產品）；
3、功能的構建方（研發）；
4、機器成本等基礎資源運維方。

2.2 收益分析

我們的系統的成本主要是研發構建成本、功能運維成本、資源成本，首先低碼手段能夠直接的降低功能的開發成本、功能優化迭代速度快之后功能運營成本也間接得到優化，由于低碼是基于Faas思想做的資源隔離部署，一定程度上也節省了機器資源。
當節省后的開發成本能蓋過新增低碼平臺的工作量時，整體收益無疑是正向的。
純代碼、無碼化、低碼化 三種方式的開發迭代成本差異，拿做只有一個玩法的活動來看：

03 代碼切入點

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

04 低碼-組裝式架構設計思路

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

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

4.1易變邏輯的處理

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

05 整體邏輯架構

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

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

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

5.1運行視圖

06 看個demo

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

6.1確定玩法

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

6.2落地金豆玩法

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

6.3落地簽到玩法

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

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

6.4落地盲盒玩法

盲盒抽獎的玩法組裝拼接也是類似的，只不過用到的基礎函數不同
1、確定配置的元數據，比如活動、獎池、獎品，及其中的對應字段
2、確定業務實體的元數據，比如用戶當前狀態、用戶中獎記錄，及其中的對應屬性
3、確定服務的輸入：開盲盒、增加盲盒機會
4、確定服務的輸出：盲盒獎品列表、開盲盒記錄
5、確定對應服務邏輯中的基礎函數：機會、周期、限制、概率、庫存等等
6、根據功能邏輯進行基礎能力的編排，同樣是三種方式，比如拖拽完成抽獎功能，當前周期、機會-1、限制消耗 1、獎池選擇、概率選擇、計數統計
7、完成對應服務的api對應

6.5玩法間的編排

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

比如說：
1、任務完成增加盲盒機會
2、簽到每連續十天上報周期任務完成
3、每日簽到增加金豆
4、消耗金豆兌換盲盒機會
5、某些高價值任務完成增加盲盒機會
6、簽到完成增加盲盒機會
這塊的具體設計可以參照之前《活動流程編排》一文。

6.6前后端的配合

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

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

07代碼建設后的收益

整體看下來低成本低碼平臺建設后，對我們的收益是很大的，整體的思路也是切實可行的，整個建設過程對于業務收益是比較大的，比如：
1、沉淀的基礎能力，除低碼平臺可以使用外，日常純代碼開發也是可以直接用的，也為無碼功能增加了一件可復用能力。
2、業務單元能力，由于迭代效率較高，功能豐富度、優化程度要更好，并且很多時候可直接復用。
3、業務功能，能力在使用過程不斷沉淀，可以直接復用，由于可以直接拖拽編排，整體的開發成本是直線下降的。
4、對于功能來說，迭代效率更高。

整體是好的，但是在低碼平臺的建設啟動及過程中需要注意的是：
1、術業有專攻，不要貪大求全，在適合且某個特定的大業務領域下建設才是合理的。
2、函數庫的積累是一個循序漸進的過程，根據訴求逐步沉淀基礎函數才是王道。
3、低碼、無碼、純代碼并不互斥，界限也相對模糊，他們只是適用于不同場景，受用不同的迭代效率和使用人群，很多時候一次性單功能純代碼開發效率最高（上低碼走彎路）、無代碼就能滿足使用人群（適用人群是運營、研發無訴求），功能性增迭代要求非常快、倒排需求較多、功能相對類似、開發資源相對匱乏的場景就很適合低碼平臺承接。
4、不要過分迷戀DSL，使用既定的工具來解決問題，現有的腳本語言、數據架構 足夠解決問題了。