背景

在 B 端領域深耕多年，接觸了成百上千的 B 端頁面，發(fā)現(xiàn)對于 B 端產(chǎn)品需求和 C 端有著明顯的差異，B端產(chǎn)品一般是基于現(xiàn)有的“業(yè)務”形態(tài)，將傳統(tǒng)線下工作，通過程序化、系統(tǒng)化、信息化轉(zhuǎn)換為線上產(chǎn)品，從而提升企業(yè)協(xié)同效率，降低辦公成本。需求一般來源于產(chǎn)品戰(zhàn)略定位、使用者個性需求等。

其中 B 端各種各樣的功能，其實就是很多 CURD 頁面的堆砌，對于 B 端這些頁面其實調(diào)性是差不多的，使用低頻，頁面重復度高，表格表單為主，功能性多且雜。

每個公司都會結(jié)合自己實際的業(yè)務抽象出一套搭建系統(tǒng)來解決 B 端場景的 CRUD 重復頁面的方案，核心就在于標準和規(guī)則的制定，對于 B 端搭建早就不是什么新鮮玩意，B 端搭建平臺的難點本身不在于有多少技術壁壘，更多的是在于從產(chǎn)品到研發(fā)再到測試整個流程的標準化，以及和業(yè)務的緊緊貼合，只有這樣才能發(fā)揮搭建平臺的價值。

二

標準

為什么說核心是標準，引用一個之前看到的通俗易懂的例子，我們小時候逢年過節(jié)穿的衣服，都是去裁縫店選一下材料、量一下尺寸，等個半個來月，討回來就可以穿了，衣服合身又喜歡。鏡頭切回今天，我們只需要在天貓、淘寶上看看圖片、選擇合適的尺寸就可以下單了，第二天就可以穿上，偶爾一絲不合身，偶爾大街上撞衫，但我們并不在意，因為我們享受到了更多的便利與高效，受益于這個產(chǎn)業(yè)制定了很多的標準化模型，比如身材模型：S、M、L、XL、XXL，我們不再需要每次都去量身高尺寸，現(xiàn)在標準化生產(chǎn)出來的衣服可以滿足超過 90% 的需求，除明星或特殊場景之外也不會費心思去量身定制。

服裝、飲食、汽車乃至各行各業(yè)發(fā)展至今都已經(jīng)形成非常成熟、高效的產(chǎn)業(yè)鏈，軟件研發(fā)行業(yè)同樣如此，業(yè)務需求在增長且變化快，越是技術密集型的工種越容易帶來人力不足的瓶頸，這就越需要更多的標準和模型的制定，標準越趨于統(tǒng)一，就越高效，有時候 “放棄創(chuàng)造力才是最大的創(chuàng)造力”，可以預見，未來絕大多數(shù)場景將使用標準化模板通過無定制或低定制來完成業(yè)務需求。

三

定位

B 端搭建平臺，設計方案上主要首先要想明白這幾個問題：

pro-code，low-code，還是 no-code？

用戶群體是誰？產(chǎn)品？運營？開發(fā)？

什么樣的頁面適合用B端搭建平臺？需要制定什么樣的標準？

我們的業(yè)務特點是什么？怎么樣的搭建方案最貼切我們的業(yè)務？

針對目前B 端的業(yè)務，更加傾向于少量代碼編寫的 low-code，主要綜合以下幾點考慮：

成本和效率因素：使用 low-code 可以實現(xiàn)快速搭建應用程序的目標，而無需具備高深的編程技能。low-code 搭建平臺提供了豐富的預定義組件和集成工具，可以減少開發(fā)時間和成本，提高開發(fā)效率。

簡化開發(fā)過程：采用 low-code 搭建平臺，用戶只需要通過簡單的拖放操作和配置即可實現(xiàn)應用程序的設計和開發(fā)。low-code 搭建平臺提供了一個可視化的開發(fā)環(huán)境，使得開發(fā)者可以更加專注于業(yè)務邏輯的實現(xiàn)。

提供更高的可定制性：使用 low-code 搭建平臺，用戶可以根據(jù)自己的需求，快速構(gòu)建自定義的組件和應用程序，而無需編寫大量的代碼。用戶可以選擇在模板中制作自己喜歡的界面和布局，并自定義相關的數(shù)據(jù)驅(qū)動器和互動部件。

降低維護負擔：使用 low-code 搭建平臺開發(fā)的應用程序通常會降低維護和更新的負擔。平臺通常支持升級和維護的自動化機制，同時在應用程序中，許多功能也由后臺機制自動化完成，簡化了開發(fā)者的工作。

因為有一定的編寫代碼成本，所以使用用戶群體就是開發(fā)，對于比較偏配置的頁面，適合用B端搭建平臺。

四

詳細設計

弄清楚了定位，結(jié)合目前后臺當前業(yè)務域的業(yè)務特點，主打配置+規(guī)則的搭建平臺樂高應運而生，下面是樂高平臺的主要設計和結(jié)構(gòu)，主要為了解決規(guī)則配置類的 CURD 頁面。

業(yè)務流程

完整流程

整體架構(gòu)

分層設計

整體采用前后端分離的架構(gòu)設計，分為視圖層、模板層、引擎層。

視圖層?

視圖層具備完善的開發(fā)和生產(chǎn)流程：基于國際JSON Schema標準，開發(fā)出獨立的組件 -> 組件經(jīng)過不同形式的排列組合，形成最終的產(chǎn)品界面。

頁面抽象定義如下：

視圖層如下圖所示，主要分為三個部分：

組件池：組件池是頁面的骨架部分，由內(nèi)置和自定義的各個組件組裝而成。可以通過拖動組件進行排列組合，即時的在預覽區(qū)域展示出效果。

畫布：畫布占據(jù)了頁面的中間部分。畫布由各個組件拼接而成。可以通過預覽能看到完整的頁面，也可以通過查看按鈕預覽生成的JSON Schema腳本。

屬性模塊：每個組件，都有可配置的屬性，選中組件可以對其屬性進行配置。如，配置按鈕組件的名稱、字段名、是否必填等，都取決于組件開發(fā)者對該組件的預留項。

模板層

統(tǒng)一收斂所有功能入口，對底層數(shù)據(jù)存儲和接口協(xié)議進行升級，提供統(tǒng)一的接口協(xié)議、鑒權(quán)、審批、灰度、回滾等功能。

模板層主要包含三個部分：

Json Schema管理：提供通用的schema接口協(xié)議，包含schema數(shù)據(jù)管理，各組件數(shù)據(jù)源統(tǒng)一查詢接口，一鍵還原schema數(shù)據(jù)等功能。

模板數(shù)據(jù)管理：包含模板數(shù)據(jù)落地，模板數(shù)據(jù)校驗、解析、搜索，以及模板數(shù)據(jù)與schema腳本的映射關系。

規(guī)則引擎適配：對模板數(shù)據(jù)進行分組，解析schema腳本和模板數(shù)據(jù)得到規(guī)則因子，根據(jù)配置的規(guī)則 + 因子項組裝規(guī)則表達式，將實際業(yè)務邏輯翻譯成規(guī)則引擎能夠識別的表達式。

引擎層

規(guī)則引擎實現(xiàn)了將業(yè)務決策從應用程序代碼中分離出來，并使用預定義的語義模塊編寫業(yè)務決策。通過入?yún)⒑鸵?guī)則表達式計算結(jié)果。

規(guī)則引擎主要包含四個部分：

規(guī)則組：對同類規(guī)則進行分組，規(guī)則組內(nèi)的規(guī)則可以互斥，也可以存在優(yōu)先級。

規(guī)則因子：對應規(guī)則表達式中的已知條件。

規(guī)則：因子 + 表達式組成，代表一條判定邏輯。

結(jié)果：規(guī)則引擎輸出的場景處理方案。

規(guī)則引擎執(zhí)行流程：

邏輯編排

以某個案例作為一個通用的業(yè)務場景，看看如何落地到業(yè)務當中，業(yè)務流程大致如下：

關鍵用例：

然后 B 端頁面進行邏輯編排，最后通過規(guī)則引擎計算出結(jié)果，規(guī)則因子和結(jié)果會根據(jù)業(yè)務提前定義好。

C 端進行消費

存儲設計

五

思考

低代碼平臺一直被業(yè)界調(diào)侃為“行業(yè)毒瘤”，相反，它是一種非常有前途的技術趨勢。低代碼搭建平臺可以幫助企業(yè)降低開發(fā)成本、縮短開發(fā)周期、增加靈活性，降本增效。

但是，有人認為低代碼平臺有著一些潛在的問題，這也是“低代碼平臺是行業(yè)毒瘤”這一說法背后的原因：

可定制性差：低代碼平臺提供的模塊化組件和界面模板可定制性有限，有可能不能滿足某些用戶的特殊需求，這使得它在某些場景下的協(xié)作和管理有一定的限制。

依賴平臺技術構(gòu)架：許多低代碼平臺采用特有的技術架構(gòu)和編程方式，容易給開發(fā)者學習和成長帶來困難，也會導致平臺的依賴性增加。

風險管理不完善：低代碼平臺對于數(shù)據(jù)安全等問題的風險管理還存在一些缺陷。在使用低代碼平臺開發(fā)的應用程序可能無法滿足某些重要的數(shù)據(jù)管理要求，例如安全性、隱私保護等因素。

存在即合理，低代碼平臺本身并非行業(yè)毒瘤，只是一個優(yōu)勢和劣勢都非常明顯的技術，切不可因噎廢食，一棍子打死所有，但如果沒有充分考量和處理相關的問題，使用低代碼平臺開發(fā)的應用程序可能會帶來一些風險和限制。因此，在選擇平臺時應根據(jù)實際需求，權(quán)衡各種因素，謹慎抉擇。

低代碼要利用，但是一定要“謹慎”，適合自己業(yè)務才是最好的。

編輯：黃飛