背景

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

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

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

二

標準

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

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

三

定位

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

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

用戶群體是誰？產品？運營？開發？

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

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

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

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

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

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

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

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

四

詳細設計

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

業務流程

完整流程

整體架構

分層設計

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

視圖層?

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

頁面抽象定義如下：

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

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

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

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

模板層

統一收斂所有功能入口，對底層數據存儲和接口協議進行升級，提供統一的接口協議、鑒權、審批、灰度、回滾等功能。

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

Json Schema管理：提供通用的schema接口協議，包含schema數據管理，各組件數據源統一查詢接口，一鍵還原schema數據等功能。

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

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

引擎層

規則引擎實現了將業務決策從應用程序代碼中分離出來，并使用預定義的語義模塊編寫業務決策。通過入參和規則表達式計算結果。

規則引擎主要包含四個部分：

規則組：對同類規則進行分組，規則組內的規則可以互斥，也可以存在優先級。

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

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

結果：規則引擎輸出的場景處理方案。

規則引擎執行流程：

邏輯編排

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

關鍵用例：

然后 B 端頁面進行邏輯編排，最后通過規則引擎計算出結果，規則因子和結果會根據業務提前定義好。

C 端進行消費

存儲設計

五

思考

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

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

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

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

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

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

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

編輯：黃飛