作者丨榮多君

1、前言

互聯(lián)網(wǎng)時代演進到現(xiàn)在，在 5G 和 IOT 的影響下，整個人類社會實現(xiàn)全產(chǎn)業(yè)數(shù)字互聯(lián)的愿景變得逐漸清晰，某個行業(yè)通過行業(yè)標準的制定，采用同一套標準，甚至同一套軟件，通過行業(yè)領域能力的復用，來快速構(gòu)建產(chǎn)業(yè)平臺，并通過需求的更新與場景的優(yōu)化，來不斷積累行業(yè)的量變，最終形成質(zhì)變。而 B 端，正是實現(xiàn)產(chǎn)業(yè)數(shù)字互聯(lián)的重要組成部分，因此，以 AT 為代表的大廠都開始把目光指向了 B 端。

與傳統(tǒng)的 B 端軟件交付廠商不同，各互聯(lián)網(wǎng)大廠憑借雄厚的產(chǎn)品與技術實力，大都已完成 C 端的業(yè)務與技術基礎設施建設，因為技術具有通用性，因此，暨希望通過現(xiàn)有產(chǎn)品和技術進行小規(guī)模的改造，來滿足 B 端（Saas 化或私有云）交付和部署，便成為各個廠商的普遍思路。

但要真正走向 B 端，做好賦能和服務，還會面臨許多困難。

2、To B 的難點

簡而言之，就是要解決“集成與被集成”的問題。

2.1. 集成與被集成

對 to B 領域的認識很容易陷入到無邊界的陷阱中，從技術和產(chǎn)品的角度去評估會認為都可以做，實際上進入更廣泛的領域之后，會發(fā)現(xiàn)各行各業(yè)大多都有自己獨特的知識體系和產(chǎn)品，一套體驗、一套流程、一套配置很難包打天下。這時，廠商就會考慮更新戰(zhàn)略，重塑業(yè)務邊界，通過引入 SI 與 ISV 來構(gòu)建產(chǎn)品生態(tài)。

引入 SI 與 ISV，除了是一種思想戰(zhàn)略的轉(zhuǎn)變，同時也是技術的變革，是從提供一個從頭到尾的完整解決方案，變?yōu)閯e人解決方案的一部分，成為 inside，實際上要求是更高了，包含了從產(chǎn)品的被集成，到技術的被集成，到生態(tài)的被集成。

2.2. 被集成的難點

本文主要談技術方面。

以近些年，互聯(lián)網(wǎng)企業(yè)在 To B 領域的實施情況來看，很多成功都是依靠投入很多精兵強將才做成的，說明互聯(lián)網(wǎng)企業(yè)，其技術面對復雜場景，離標準化輸出、快速復用、方便二開還有一定的距離。To B 解決方案無論是在公有云還是專有云上，和自有技術產(chǎn)品實施相比，存在很多差異和問題：

• ISV、SI 和客戶自己的實現(xiàn)難以保證效果；
• 標準產(chǎn)品與定制開發(fā)要筑起柵欄，實施二開不能泄露核心代碼；
• 開發(fā)完成的前后端組件，需要結(jié)構(gòu)化沉淀成為可復用的二方庫；
• 前后端組件往往無法直接復用，特別是業(yè)務級別組件；
• 產(chǎn)品化的程度、產(chǎn)品說明文檔的完善和易用；
• 開發(fā)一個產(chǎn)品的方法論、流程和平臺；

To B 的產(chǎn)品能否成功，取決于生態(tài)，生態(tài)取決于能否吸引到 ISV 和 SI，而吸引到 ISV 和 SI 的關鍵環(huán)節(jié)，在于平臺能否滿足 ISV 和 SI 的需求。

落到更細節(jié)的技術方面，SI 與 ISV 需要什么？

靈活定制：前后端都提供靈活的二開機制，前端提供搭積木的自由組裝的能力；后端提供靈活的功能擴展能力，能夠?qū)⒍ㄖ拼a與核心代碼完全分離；同時支持流程定制、元數(shù)據(jù)擴展、服務編排。

快速交付：盡快產(chǎn)出原型（方便復用）、盡快交付產(chǎn)品（積木式、配置化地組合業(yè)務，基于基線能力快速地擴展和定制能力）。

提高生產(chǎn)率：提供功能完整的應用開發(fā)平臺，并提供主流 IDE、Maven 插件來提升開發(fā)效率效率，基于 CICD 平臺來實現(xiàn)打包部署自動化。To B 端常見的表單和列表的 CRUD，能夠直接根據(jù)視圖生成邏輯并映射到數(shù)據(jù)對象和物理表。

WORA：Write Once，Run Anywhere，前端一套代碼能夠在 PC、Mobile、小程序運行（Electron、flutter、taro1.3 等框架提供了技術上的可行性）。

Hotpatch：以往比較成熟的方案是移動端基于 jspatch、multiDex 等方案實現(xiàn) hotpatch，但由于 ios 管控及小程序生態(tài)的崛起，目前小程序化成為 hotpatch 的主流選擇。

運行時態(tài)可配置：提供線上前后端的配置平臺，實時生效。

使用門檻低：提供所見即所得的開發(fā) IDE，并且支持各種主流語言。

學習成本低：可視化開發(fā)平臺；完備的文檔、Demo、視頻；使用引導和幫助；playground、官網(wǎng)或開發(fā)者社區(qū)。

可以看到，To B 的軟件開發(fā)考慮的維度要多于自有產(chǎn)品技術實施，它所面對的不僅僅是有和無的問題，關鍵在于平臺的整合建設，這么說，未來 To B 戰(zhàn)場的，誰最先整合出領域技術平臺，誰就能握有生態(tài)，誰就能成為事實上的標準和規(guī)范。

2.3 解決難點要考慮的方面

要設計一個解決 ISV 和 SI 的痛點、滿足業(yè)務開發(fā)和擴展的需要，具備靈活的二開能力，并且方便使用的 To B 應用開發(fā)平臺，需要考慮很多方面：

首先，從分層的角度來看，管理一個 To B 的產(chǎn)品或解決方案，要有一個可視化的研發(fā)過程管理平臺

向 ISV 及 SI 提供統(tǒng)一的研發(fā)過程管理平臺、注入統(tǒng)一的開發(fā)流程和理念是非常有必要的，這不僅可以降低合作伙伴接入生態(tài)的難度，也可以增強 ISV 和 SI 進行項目開發(fā)的規(guī)范性；同時基于平臺對項目過程數(shù)據(jù)進行結(jié)構(gòu)化地存儲，以利于后續(xù)利用大數(shù)據(jù)進行效率、利潤、成本的核算。這個研發(fā)過程管理平臺包括項目管理功能，同時對接前端和后端平臺進行開發(fā)，并且提供質(zhì)量管理和人員管理的工具，最后可以方便對解決方案和項目進行集成和發(fā)布。

其次，平臺整體架構(gòu)應該如何分層，各層的數(shù)據(jù)模型應該如何定義，數(shù)據(jù)模型之間如何進行映射和轉(zhuǎn)化。比如前端與業(yè)務后端的銜接，定義一套標準的 View Object 對象（包括擴展標簽），由 API GW 進行解耦，通過視圖 id 或 name 進行數(shù)據(jù)操作。再次，ISV 與 SI 的客戶定制代碼與核心產(chǎn)品代碼如何完全隔離，這里涉及到兩個二方面：

• 首先說前端，前端架構(gòu)由傳統(tǒng)的 Page Route，改為 Component Route，Page 變?yōu)榧兇獾娜萜?，這樣帶來的巨大好處是，UI 組件與 Page 解耦，使得 UI 組件成為類似于微服務一樣的獨立實體，這樣，UI 組件就可以脫離 Page 實現(xiàn)任意的組合，這就是“積木式”，同時，UI 組件，可以提供 Setter 擴展方式來增強組件功能、展示、甚至綁定不同的后端 API，實現(xiàn)二開；
• 再來說后端，將基礎能力和業(yè)務定制能力分層，兩者提供不同的注解（@Domain 代表領域基本業(yè)務，@Business 代表領域定制業(yè)務），行業(yè)定制基于基礎能力所暴露的 SPI 進行定制開發(fā)，在不修改基礎能力代碼的前提下，實現(xiàn)功能的定制，基礎能力和業(yè)務定制能力都支持通過 SPI 來定義服務的擴展點；數(shù)據(jù)層面，通過定義數(shù)據(jù)視圖，對不同元數(shù)據(jù)進行聚類、組合，以實現(xiàn)運算的目的，同時能夠以不同的形式對后端數(shù)據(jù)進行展現(xiàn)。

然后，業(yè)務流程如何編排，這里業(yè)界有不同的做法，本文中推薦在前端基于組件實現(xiàn)可視化的業(yè)務流，在微服務的架構(gòu)下，前端組件一般 1v1 對應后端接口，通過用可視化（組件之間的關系連線）方式定義前端組件之間的調(diào)用關系，間接建立后端功能流程的調(diào)用鏈。

再后，基于 API 網(wǎng)關實現(xiàn)前后端的分離，實現(xiàn)接口級別的熔斷、權(quán)限、安全、降級等策略；同時提供日志管理和異常監(jiān)控（包括穩(wěn)定性監(jiān)控和業(yè)務異常監(jiān)控）。

最后，基于 CICD 平臺，能夠基于 yaml 將前后端應用單個或整體快速拉起，以實現(xiàn)解決方案級別的快速部署和升級。同時自動將產(chǎn)品的功能模塊沉淀回中臺，并將項目過程數(shù)據(jù)作結(jié)構(gòu)化存儲，作為二次開發(fā)的基礎能力。

3、應用開發(fā)平臺的架構(gòu)設計

根據(jù) 2.3 的考慮，一個完整的 To B 應用開發(fā)平臺架構(gòu)總體可以劃分為 5 個部分，分別是項目管理層、前端拼裝層、后端能力層、底層框架和 Runtime Infrastructure。

項目管理層主要是提供一個研發(fā)過程管理平臺，方便 ISV 和 SI 可視化管理項目和需求，對接 Runtime Infrastructure，并提供前后端開發(fā)工具。

前端拼裝層分為二部分，基礎部分與 APIGW 對接，基于 VO 建模，可視化配置和綁定業(yè)務能力接口；拼裝部分基于可視化編輯器提供前端組件的積木式組裝。

后端能力層分為二部分，基礎能力封裝業(yè)務核心代碼，用于快速構(gòu)建基線能力；定制能力主要基于 SDK 進行定制開發(fā)，基于 SPI 擴展點，利用多態(tài)特性實現(xiàn)定制。

開發(fā)框架主要是提供 SDK（封裝注解及定義）方便定制開發(fā)、vs studio plugin 和 maven 插件用于打包發(fā)布。

Runtime Infrastructure 包括 CICD、日志、運行監(jiān)控、自動化測試等能力。

一、研發(fā)過程管理平臺的架構(gòu)設計方案

除了編碼采用線下開發(fā)（提供必要的 plugin、sdk，如果部署方式走 serverless，可以考慮集成 monaco 進行定制，實現(xiàn)線上 coding->compile->test->deploy 一體化），其它包括項目管理、需求管理、版本管理、工程管理均可在該平臺上集成并進行日常管理。同時，研發(fā)過程管理平臺還可通過對接前端開發(fā)平臺、后端開發(fā)平臺、CICD 平臺、質(zhì)量管理平臺、帳戶體系形成一個完整的應用開發(fā) studio。

二、前端業(yè)務組件拼裝的架構(gòu)設計方案

裝修編輯器：提供支持相對布局絕對布局的編輯器，提供包括頁面布局調(diào)整、樣式調(diào)整、組件拖拽展示、預覽、屬性設置在內(nèi)的所見即所得的功能體驗。

復用沉淀機制：前端拼裝的基本粒度是業(yè)務組件，能完成具體業(yè)務動作的，與后端能?連接的（可選）業(yè)務組件，? ?交互 / 基礎組件。舉例來說，商品列表、購物車、買家訂單列表都是前端拼裝中的組件，? Button 、Input 、Toast 等屬于基礎組件（Base Component），不是前端拼裝會操作的組件級別。版本發(fā)布時，新開發(fā)或修改的組件經(jīng)過 webpack 打包成 npm 包，上傳 npm 倉庫，用于下次開發(fā)復用。

業(yè)務流編輯器：用于描述前端組件之間關聯(lián)關系的編輯器（所謂關聯(lián)關系，目前可以淺顯地表現(xiàn)為組件跳轉(zhuǎn)顯示關系，實際上由于每個業(yè)務組件都與后端 API 關聯(lián)，也代表了后端的調(diào)用流程），提供 4 種基礎概念元件，分別為 Process、Branch、Begin、End，每個概念元件均可以綁定特定業(yè)務組件，在編輯器上將概念元件連線，然后通過組件內(nèi)部實現(xiàn)的“出入口”機制，實現(xiàn)組件與組件之間的跳轉(zhuǎn)關系。

頁面管理：頁面在業(yè)務組件化的前端系統(tǒng)中，作為業(yè)務組件的容器，承載布局信息。

后端服務綁定：每個組件都能有選擇地綁定 1 到多個后端 API，當點擊該組件中某個控件的響應操作時，會觸發(fā)對后端 API 的調(diào)用。這樣的好處是，解決方案部署的同時復用了前后端的功能和體驗，可以快速生成原型或交付件。

同時，為了提升開發(fā)體驗和效率，需要配套提供開發(fā) SDK、集成開發(fā)環(huán)境的插件（vsc plugin 等）、以及包括配置、告警、監(jiān)控、A/B Test 等在內(nèi)的公共基礎能力。

三、后端開放性架構(gòu)設計方案

由后端服務提供服務 SDK，前端組件通過該 SDK 對后端網(wǎng)關暴露的 API 進行綁定，事實上建立了業(yè)務組件與后端服務的關聯(lián)關系，這種綁定方式是去代碼化的，并且基于精巧設計的、對象化的、功能兼容的接口（例如 graphql）可以實現(xiàn)動態(tài)切換（免代碼修改）。

Domain Service（領域服務）通過對領域功能和流程進行抽象，提供基線（標準）功能，并對領域數(shù)據(jù)封裝原子級別的操作入口。

Business Service（業(yè)務服務 / 定制服務）基于 Domain Service 提供的擴展點（SPI）實現(xiàn)功能和流程的定制。

Domain 和 Business 可以實現(xiàn)完全的代碼隔離，這對于生態(tài)的知識產(chǎn)權(quán)保護非常關鍵。

DB 和數(shù)據(jù)訪問層主要作用是對 Domain 標準定義進行領域數(shù)據(jù)建模，同時針對業(yè)務提供數(shù)據(jù)建模的擴展能力，并且服務于 B 端，還需要充分考慮租戶間數(shù)據(jù)隔離和數(shù)據(jù)跨應用聯(lián)通的方案。

3.1 前端的開放性設計

前端的開放性設計涉及到 4 個維度：業(yè)務組件、沉淀與復用、業(yè)務流、組件的擴展。

3.1.1 組件業(yè)務化及跨平臺化

這里的業(yè)務組件，如前面所述，是能夠觸發(fā)或完成一個業(yè)務動作、與后端能力連接的業(yè)務組件，??交互 / 基礎組件。這樣，一個業(yè)務組件實際上封裝了端到端的邏輯（前端的操作、體驗，后端的功能、數(shù)據(jù)）。使用一個業(yè)務組件，實際上也使用了與其綁定的后端能力和數(shù)據(jù)

另外，由于 To B 市場在端側(cè)的多樣性，從成本的現(xiàn)實考慮，前端組件跨平臺的需求也非常常見，近幾年，由于 Electron、微信小程序、RNWeex 等技術的成熟，類 html css js 已經(jīng)成為事實上跨多端的首選技術。

PC 端與 Mobile 端由于體驗的差異，組件往往不能共享，但通過一定的表現(xiàn)式語法抽象（suning DSL），通過提供 DSL parse sdk 對抽象語法解析，提供更高層次響應式的解釋和適配（如，在 PC 端可以解釋渲染為 List，在 Mobile 端可以解釋渲染為 ListView），可以在一定條件下實現(xiàn) Write Once Run Anywhere。

3.1.2 沉淀與復用

前端工程在開發(fā)之初，定義 PRD（這種 PRD 是一種電子化的，可結(jié)構(gòu)化定義并存儲的 PRD），并在平臺上創(chuàng)建解決方案。

復用：新迭代或新應用開發(fā)時，根據(jù)業(yè)務需求，可以到業(yè)務組件倉庫中尋找（類似于 AppStore），如果是已有且可復用能力，則由平臺直接添加 NPM 依賴到對應開發(fā)工程中，對于不具備的能力，標識為 todo。

沉淀：當業(yè)務組件開發(fā)完成，通過在 CICD 平臺配置腳本，同時沉淀業(yè)務組件的 NPM 包，并更新 PRD，為下次復用準備。

這種沉淀和復用機制，以業(yè)務功能維度進行，實現(xiàn)了代碼的完全隔離，并依賴平臺，可實現(xiàn)完全的自動化。

3.1.3 業(yè)務流

單獨對組件粒度進行復用依然會帶來不必要的重復工作量，同時組件間也需要?種機制進行串聯(lián)。頁面組是?種?式，將?個高度相關的頁面做成?個頁面組，彼此通過相對 url 串聯(lián)。但某些交叉頁面（例如商家后臺首頁）可能會是多個業(yè)務行為的入口，包含多個業(yè)務組件，如果有關系的頁面都做成頁面組，那?個頁面組可能會包含很多個業(yè)務?為；如果將這種交叉頁面從頁面組中拿掉，?會導致頁面組本身不完整；后臺系統(tǒng)較少交叉頁面，而前臺系統(tǒng)會有很多。所以通過定義業(yè)務流（操作流），并定義等價組件（Equivalent Component），來解決上面的問題，使分解?個站點成為多個業(yè)務行為并再組合成為可能。

3.1.4 組件的擴展

首先，通常的業(yè)務組件，其邊界是模糊的，并且與應用頁面的緊密耦合，導致其無法被內(nèi)聚實現(xiàn)，并進行復用。其原因主要有兩點：

1、應?內(nèi)邏輯由 url 串聯(lián)，url 屬于應?全局的信息，但會出現(xiàn)在業(yè)務組件內(nèi)部；

2、使?全局狀態(tài)管理，組件間共享狀態(tài)，但往往未經(jīng)過良好 設計，導致組件間有隱式的互相依賴；

因此，需要將顯式的 url 從組件內(nèi)移除，引入出口概念，組件自定義出口（行為和參數(shù)），將出口行為和出口目標分離，并提供業(yè)務組件級別的狀態(tài)管理，狀態(tài)可在業(yè)務組件內(nèi)的繼承組件間共享，但不可以在業(yè)務組件間共享。

其次，由于組件具有業(yè)務屬性，而業(yè)務之間往往存在一種固有的流程機制（如加車 ->下單 ->支付），通常的方案，是建立一組 Page 的集合（Page Group），彼此通過相對 url 建立關聯(lián)。但某些 Page 包含多個業(yè)務行為的入口（如首頁樓層），如果有關系的 Page 都做成 Page Group，那一個 Page Group 可能會包含很多個業(yè)務行為，無法復用；如果將這種場景排除掉，又會導致方案本身的不完整。因此，基于頁面來復用這種業(yè)務關聯(lián)是不合適的（如前所說，Page 只是一種容器）如果建立一種串聯(lián)機制，可以動態(tài)地定義業(yè)務組件之間的關系，便可以脫離 Page 的限制，實現(xiàn)真正的解耦。

因此，可以引入業(yè)務流（操作流）的概念，動態(tài)地定義組件之間的關聯(lián)關系，使復雜業(yè)務關系的復用和重組成為可能。

業(yè)務流（操作流）是一組具有關聯(lián)關系的業(yè)務組件的集合，通過數(shù)據(jù)結(jié)構(gòu)定義組件之間的關聯(lián)關系，通過這種方式將業(yè)務流觸發(fā)條件和行為封裝在操作流內(nèi)部，不再受 UI 變化的影響，也就規(guī)避了以往頁面變化時，url 和調(diào)用方式需要重新實現(xiàn)的問題。

實現(xiàn)組件間跳轉(zhuǎn)的邏輯：

1、Component 描述出口方法和數(shù)據(jù)對象

2、在業(yè)務流（Business Unit）中獲取 SourceComponent 組件的出口 output 定義，執(zhí)行 output 方法，命中 TargetComponent。

3、獲取 TargetComponent 所在的 Page，匹配 output 或 URL，設定跳轉(zhuǎn)方式，并執(zhí)行跳轉(zhuǎn)。

最后，來講一下組件本身的擴展。

UI 的實時響應式擴展：依賴于 ReactVueAngular 等響應式前端框架，利用組件的單向 / 雙向數(shù)據(jù)綁定能力，當組件的屬性發(fā)生變化時，VDOM 會對變更部分進行實時的局部渲染。利用這個特性，我們可以設計一種組件的 Setter 機制，這是一種屬性的注入器，利用 js 實現(xiàn)，當變更組件的某個屬性，比如背景色、分欄、圖片等，可以實時地對反饋到組件的展現(xiàn)部分。對于功能部分的擴展：可以對組件現(xiàn)有能力進行兼容或非兼容性升級，重新發(fā)布到線上，并通過組件更新機制來實現(xiàn)功能擴展。

3.2 后端的開放性設計

前端組件應對了業(yè)務場景化需求，但這個復用顆粒度對于業(yè)務邏輯和數(shù)據(jù)而言仍然比較粗，因為即使是不同的場景，內(nèi)部的邏輯和數(shù)據(jù)結(jié)構(gòu)依然可以復用。而且，后端大都采用了微服務架構(gòu)，各系統(tǒng)提供了原子接口，不同的原子接口匯聚成一個個標準業(yè)務流程，但在 To B 的生態(tài)中，定制與擴展的場景很常見，比如：

基線提供的業(yè)務流程，在交付給 A 和 B 的過程中，都有存在定制變更的可能性，當然，對于這種場景，可以通過在基線中做個功能全集，然后定義不同的業(yè)務參數(shù)或配置來開關，但還有些場景是開關和配置無法滿足的，比如互斥和擴展的場景：

這個時候，要么拉分支自己改，但這樣做后續(xù)代碼分支多了很難合并收斂，增加運維成本；如果讓 ISV 和 SI 維護分支，又冒著核心代碼公開的風險。

因此，如果能設計一種靈活二開的后端開發(fā)框架，由 ISV 和 SI 根據(jù)業(yè)務定制需求進行擴展，便有了必要性。

3.2.1 架構(gòu)和流程

將后端服務劃分為：網(wǎng)關、業(yè)務定制層和基礎能力層。其中網(wǎng)關主要作用是對外暴露 API，Business 和 Domain 的服務都負責各自領域的業(yè)務建模，包括自己的元數(shù)據(jù)建模和視圖建模，Business 和 Domain 都對外提供服務，不同的是，Domain 提供提 SPI，是可復用、可擴展的點。而 Business 可以提供 SPI，也可以提供 API，視具備策略而定。

上圖是一個二開的示意流程，在每個變更點，添加待實現(xiàn)的 SPI，并在平臺結(jié)構(gòu)化落庫。在網(wǎng)關上添加（新增）或修改（現(xiàn)有）API，指向該 SPI，此時，前端可以在平臺上查詢到該新增的 API。通過元數(shù)據(jù)建模和視圖建模，并結(jié)構(gòu)化存儲到平臺上，前端可通過平臺查詢到視圖信息，根據(jù)視圖的 schema 可以進行前端開發(fā)。后端則實現(xiàn)該 SPI，并通過 CICD 發(fā)布沉淀到平臺中，用于交付及后續(xù)復用。

3.2.2 SPI

SPI 是后端框架實現(xiàn)開發(fā)性設計的關鍵元素，它由服務的提供者來定義，確定命名空間、方法名、出入?yún)ⅲ脚_上的 SPI 可以簡單對應到 java 世界中一個單方法的 interface。

Business 和 Domain 對外暴露 SPI（Business 可以暴露 API），通過對 SPI 定義、迭代、調(diào)度、復用和沉淀實現(xiàn)能力的開放。

注解：

@BusinessSPI 業(yè)務應用層 SPI 注解

@DomainSPI 領域中心層 SPI 注解

SPI 定義的步驟：

1、從平臺上創(chuàng)建的 git repo 上 clone 到可開發(fā)的 maven 工程

2、在工程目錄的對應目錄中編寫 spi 定義，并加上 @SPI 注解

3、命名工程中提供的 maven 插件打包，插件會將 spi 信息抽取并提交到平臺。

4、平臺會生成實際可用的 jar 并發(fā)布到 maven 倉庫，返回操作成功與否等信息，開發(fā)者可以在編譯打印中查看。

SPI 定義的示例：

通過定義 SPI 對外暴露各類可定制點，利用 java 的多態(tài)性，針對不同的業(yè)務場景定制不同的 Impl。在實際的使用中，框架還需要支持 version、多租戶等層面的信息，用于確保路由的正確性。

目前的二開，主要是通過 SPI 的機制，在現(xiàn)有產(chǎn)品和解決方案的 Domain 能力基礎上進行覆寫或擴展，實際使用中，可能存在以下幾種情況：

1、給定的 SPI 抽象準確，現(xiàn)有的實現(xiàn)代碼滿足要求，則直接使用現(xiàn)有鏡像。

2、給定的 SPI 抽象準確，現(xiàn)有的實現(xiàn)無法滿足要求，則重寫一個新實現(xiàn)。

3、給定的 SPI 抽象不準確，邏輯無法滿足要求，則定義一個新的 SPI 并實現(xiàn)。實際使用場景中，@注解還可以細分成多種：

1）命令式申明注解 @BusinessCMDSPI、@DomainCMDSPI

2）查詢式申明注解 @BusinessQuerySPI、@DomainQuerySPI

3.2.3 元數(shù)據(jù)

元數(shù)據(jù)提供 @Entity 注解來申明定義。

元數(shù)據(jù)不支持嵌套（主要是因為復雜，同時不是必要），一個 Entity 內(nèi)部的成員變量不能是 Entity。

元數(shù)據(jù)參數(shù)存儲上支持字段擴展，采用屬性值表設計，原來應用配置的數(shù)據(jù)源會退化為元數(shù)據(jù)后端的地址；元數(shù)據(jù)后端提供視圖映射功能，可以針對元數(shù)據(jù)直接做聚合查詢，并直接生成 SPI 及對應 SPI 的實現(xiàn)代碼。

Entity 定義后實際可能會映射到多張物理表，整體方案從技術上來說，主要難度在于事務處理上，目前來看短期內(nèi)沒法構(gòu)建一套可靠穩(wěn)定的方案，因此，操作內(nèi)部實現(xiàn)目前走 mapper 并直連數(shù)據(jù)源，但對外暴露統(tǒng)一的 load/save 方法。

定義及沉淀流程：

1、開發(fā)時，定義 Entity 并申明 @Entity 注解，通過 IDE 插件解析注解，將本地元數(shù)據(jù)定義 DSL Push 到平臺服務，平臺根據(jù)定義自動識別變更、合法性，生成物理庫表。

2、IDE 插件提供一套類似 lombok 的編譯器修改抽象語法樹的機制，給元數(shù)據(jù)提供 load/save 等方法。

3、增加元數(shù)據(jù) save 擴展點方便 handle 業(yè)務代碼插入。

4、運行時，具體的 load 和 save 方法會調(diào)用元數(shù)據(jù)后端提供的 RPC 服務。

5、發(fā)布時，元數(shù)據(jù)地根據(jù) Application 類名，并變更自動生成的版本號。

3.2.4. 視圖

在 To B 的應用中，表單和列表占據(jù)半壁江山，可以針對典型的中后臺應用表單進行抽象，輸出一份通用 scheme，基于該 scheme 進行視圖建模。

業(yè)務上很多場景化查詢需求，如果這部分實現(xiàn)全部落到 Domain 層，對 Domain 層的穩(wěn)定性是個沖擊，視圖建模和視圖查詢主要應對這些場景。

在后端平臺側(cè)提供視圖建模功能，可以自由搜索元數(shù)據(jù)，選擇需要的字段，組合成新的視圖，開發(fā)人員需要給出元數(shù)據(jù)字段到視圖字段的 mapping 關系，以及指定視圖的 id 作為唯一標識，并進行發(fā)布。

發(fā)布后，平臺自動生成對應的 @BusinessSPI 或 @BusinessQuerySPI 定義和實現(xiàn)，package 成 jar，并 Push 到 maven，對應視圖的查詢和簡單的 CRUD 結(jié)果集便可自動生成。

如果修改視圖，在平臺上修改視圖字段，平臺重新生成相關的查詢 SPI 和實現(xiàn)，并自動變更視圖 version。

在視圖關聯(lián)數(shù)據(jù)庫方面，如果采用的是物理庫表，則可能會出現(xiàn)一個視圖對應關聯(lián)多個庫表聯(lián)合查詢的情況，這個邏輯比較復雜，考慮了 2 種方案：

1、落到 es 進行查詢，走 mysql->canal->es 的方案

2、走邏輯大寬表方案

3.3 前后端的銜接設計

同步 VO 與根據(jù) VO 獲取數(shù)據(jù)進行分離，由 API GW 進行解耦，通過視圖 id 或 name 進行數(shù)據(jù)操作。前端通過特定接口獲取到該應用的所有 vo，并進行列表展現(xiàn)。每個 vo 都有對應的 version，用于同步 VO 的變更。

前端平臺提供 loader 或 parser 解析視圖 VO，反向渲染生成組件。

后端平臺通過搜索元數(shù)據(jù)，選擇需要的字段，組合成新的數(shù)據(jù)視圖 -DO，后端平臺自動生成對應的 @BusinessSPI 或 @BusinessQuerySPI 定義和實現(xiàn)，package 成 jar，并 Push 到 maven，開發(fā)本地應用。（對于某些 VO 和 DO 直接一對一映射的場景，前端也可以考慮直接使用 DO）

根據(jù)上圖，開發(fā)平臺的基本流程和各層功能為：

1、基本流程：數(shù)據(jù)對象 DO->SPI->API->展現(xiàn)視圖 VO->組件 ->UI，前端業(yè)務組件直接與后端 SPI 及數(shù)據(jù)對象進行映射。

2、前端拼裝：

1) 提供編輯器，支持絕對布局和相對布局，可以由 VO 直接生成業(yè)務組件；也可以采用類 Axure 手工拼裝成組件，并綁定后端 API。

2) 支持基于現(xiàn)有業(yè)務組件，通過業(yè)務流（操作流）和 Setter 機制來擴展組件能力。

3、后端能力：在 Business 和 Domain 都支持通過 SPI 來定義服務的擴展點，ISV 和 SI 可以在不修改原有邏輯的基礎上，通過替換 SPI 來實現(xiàn)功能的替換、升級和擴展。

4、數(shù)據(jù)層面：通過將前端組件與后端 SPI 及數(shù)據(jù)對象進行映射，若對元數(shù)據(jù)對象進行新增或變更時：

1）可以直接動態(tài)變更 UI 的展現(xiàn)形式和內(nèi)容，無須修改前后端代碼

2）通過定義數(shù)據(jù)視圖，能夠根據(jù)業(yè)務訴求，對不同元數(shù)據(jù)進行聚類、組合、以實現(xiàn)運算的目的，同時能夠以不同的組件形式對后端數(shù)據(jù)進行展現(xiàn)

4、結(jié)語

從云計算的發(fā)展趨勢來看，從 Iaas 開始，未來必將在 Saas 結(jié)束（Paas 因為包括各種標準化組織和開源社區(qū)的存在，未來少有溢價的可能）。而 Saas 也是議價空間和增值空間最多的地方，未來哪家企業(yè)能夠首先完成對各個行業(yè)和領域的在核心生產(chǎn)流程和業(yè)務抽象，整合更多更優(yōu)秀的 ISV 和 SI 資源、甚至社區(qū)的力量，誰就能成為事實上的標準。

對于 To B 領域的玩家，應該走開放生態(tài)的道路，做生態(tài)，就是做標準；做平臺，就是做信任；做開放，就是做共贏。

作者簡介

榮多君，蘇寧科技集團 O2O 平臺研發(fā)中心副總監(jiān)，多年 ICT 及互聯(lián)網(wǎng)工作經(jīng)驗，曾先后就職于華為、阿里巴巴，現(xiàn)在蘇寧從事 O2O 新零售業(yè)務及平臺的建設，擅長前后端主流技術、移動互聯(lián)網(wǎng)平臺建設及服務治理、云原生及中臺技術。