前言
互聯網時代演進到現在，在 5G 和 IOT 的影響下，整個人類社會實現全產業數字互聯的願景變得逐漸清晰，某個行業通過行業標準的制定，採用同一套標準，甚至同一套軟件，通過行業領域能力的複用，來快速構建產業平臺，並通過需求的更新與場景的優化，來不斷積累行業的量變，最終形成質變。而 B 端，正是實現產業數字互聯的重要組成部分，因此，以 AT 爲代表的大廠都開始把目光指向了 B 端。
與傳統的 B 端軟件交付廠商不同，各互聯網大廠憑藉雄厚的產品與技術實力，大都已完成 C 端的業務與技術基礎設施建設，因爲技術具有通用性，因此，暨希望通過現有產品和技術進行小規模的改造，來滿足 B 端（Saas 化或私有云）交付和部署，便成爲各個廠商的普遍思路。
但要真正走向 B 端，做好賦能和服務，還會面臨許多困難。
To B 的難點
簡而言之，就是要解決“集成與被集成”的問題。
集成與被集成
對 to B 領域的認識很容易陷入到無邊界的陷阱中，從技術和產品的角度去評估會認爲都可以做，實際上進入更廣泛的領域之後，會發現各行各業大多都有自己獨特的知識體系和產品，一套體驗、一套流程、一套配置很難包打天下。這時，廠商就會考慮更新戰略，重塑業務邊界，通過引入 SI 與 ISV 來構建產品生態。
引入 SI 與 ISV，除了是一種思想戰略的轉變，同時也是技術的變革，是從提供一個從頭到尾的完整解決方案，變爲別人解決方案的一部分，成爲 inside，實際上要求是更高了，包含了從產品的被集成，到技術的被集成，到生態的被集成。
被集成的難點
本文主要談技術方面。
以近些年，互聯網企業在 To B 領域的實施情況來看，很多成功都是依靠投入很多精兵強將才做成的，說明互聯網企業，其技術面對複雜場景，離標準化輸出、快速複用、方便二開還有一定的距離。To B 解決方案無論是在公有云還是專有云上，和自有技術產品實施相比，存在很多差異和問題：
-
ISV、SI 和客戶自己的實現難以保證效果；
-
標準產品與定製開發要築起柵欄，實施二開不能泄露核心代碼；
-
開發完成的前後端組件，需要結構化沉澱成爲可複用的二方庫；
-
前後端組件往往無法直接複用，特別是業務級別組件；
-
產品化的程度、產品說明文檔的完善和易用；
-
開發一個產品的方法論、流程和平臺；
To B 的產品能否成功，取決於生態，生態取決於能否吸引到 ISV 和 SI，而吸引到 ISV 和 SI 的關鍵環節，在於平臺能否滿足 ISV 和 SI 的需求。
落到更細節的技術方面，SI 與 ISV 需要什麼？
靈活定製：前後端都提供靈活的二開機制，前端提供搭積木的自由組裝的能力；後端提供靈活的功能擴展能力，能夠將定製代碼與核心代碼完全分離；同時支持流程定製、元數據擴展、服務編排。
快速交付：儘快產出原型（方便複用）、儘快交付產品（積木式、配置化地組合業務，基於基線能力快速地擴展和定製能力）。
提高生產率：提供功能完整的應用開發平臺，並提供主流 IDE、Maven 插件來提升開發效率效率，基於 CICD 平臺來實現打包部署自動化。To B 端常見的表單和列表的 CRUD，能夠直接根據視圖生成邏輯並映射到數據對象和物理表。
WORA：Write Once，Run Anywhere，前端一套代碼能夠在 PC、Mobile、小程序運行（Electron、flutter、taro1.3 等框架提供了技術上的可行性）。
Hotpatch：以往比較成熟的方案是移動端基於 jspatch、multiDex 等方案實現 hotpatch，但由於 ios 管控及小程序生態的崛起，目前小程序化成爲 hotpatch 的主流選擇。
運行時態可配置：提供線上前後端的配置平臺，實時生效。
使用門檻低：提供所見即所得的開發 IDE，並且支持各種主流語言。
學習成本低：可視化開發平臺；完備的文檔、Demo、視頻；使用引導和幫助；playground、官網或開發者社區。
可以看到，To B 的軟件開發考慮的維度要多於自有產品技術實施，它所面對的不僅僅是有和無的問題，關鍵在於平臺的整合建設，這麼說，未來 To B 戰場的，誰最先整合出領域技術平臺，誰就能握有生態，誰就能成爲事實上的標準和規範。
解決難點要考慮的方面
要設計一個解決 ISV 和 SI 的痛點、滿足業務開發和擴展的需要，具備靈活的二開能力，並且方便使用的 To B 應用開發平臺，需要考慮很多方面：
首先，從分層的角度來看，管理一個 To B 的產品或解決方案，要有一個可視化的研發過程管理平臺
向 ISV 及 SI 提供統一的研發過程管理平臺、注入統一的開發流程和理念是非常有必要的，這不僅可以降低合作伙伴接入生態的難度，也可以增強 ISV 和 SI 進行項目開發的規範性；同時基於平臺對項目過程數據進行結構化地存儲，以利於後續利用大數據進行效率、利潤、成本的核算。這個研發過程管理平臺包括項目管理功能，同時對接前端和後端平臺進行開發，並且提供質量管理和人員管理的工具，最後可以方便對解決方案和項目進行集成和發佈。
其次，平臺整體架構應該如何分層，各層的數據模型應該如何定義，數據模型之間如何進行映射和轉化。比如前端與業務後端的銜接，定義一套標準的 View Object 對象（包括擴展標籤），由 API GW 進行解耦，通過視圖 id 或 name 進行數據操作。再次，ISV 與 SI 的客戶定製代碼與核心產品代碼如何完全隔離，這裏涉及到兩個二方面：
-
首先說前端，前端架構由傳統的 Page+Route，改爲 Component+Route，Page 變爲純粹的容器，這樣帶來的巨大好處是，UI 組件與 Page 解耦，使得 UI 組件成爲類似於微服務一樣的獨立實體，這樣，UI 組件就可以脫離 Page 實現任意的組合，這就是“積木式”，同時，UI 組件，可以提供 Setter 擴展方式來增強組件功能、展示、甚至綁定不同的後端 API，實現二開；
-
再來說後端，將基礎能力和業務定製能力分層，兩者提供不同的註解（@Domain 代表領域基本業務，@Business 代表領域定製業務），行業定製基於基礎能力所暴露的 SPI 進行定製開發，在不修改基礎能力代碼的前提下，實現功能的定製，基礎能力和業務定製能力都支持通過 SPI 來定義服務的擴展點；數據層面，通過定義數據視圖，對不同元數據進行聚類、組合，以實現運算的目的，同時能夠以不同的形式對後端數據進行展現。
然後，業務流程如何編排，這裏業界有不同的做法，本文中推薦在前端基於組件實現可視化的業務流，在微服務的架構下，前端組件一般 1v1 對應後端接口，通過用可視化（組件之間的關係連線）方式定義前端組件之間的調用關係，間接建立後端功能流程的調用鏈。
再後，基於 API 網關實現前後端的分離，實現接口級別的熔斷、權限、安全、降級等策略；同時提供日誌管理和異常監控（包括穩定性監控和業務異常監控）。
最後，基於 CICD 平臺，能夠基於 yaml 將前後端應用單個或整體快速拉起，以實現解決方案級別的快速部署和升級。同時自動將產品的功能模塊沉澱回中臺，並將項目過程數據作結構化存儲，作爲二次開發的基礎能力。
應用開發平臺的架構設計
根據前文的考慮，一個完整的 To B 應用開發平臺架構總體可以劃分爲 5 個部分，分別是項目管理層、前端拼裝層、後端能力層、底層框架和 Runtime Infrastructure。
項目管理層主要是提供一個研發過程管理平臺，方便 ISV 和 SI 可視化管理項目和需求，對接 Runtime Infrastructure，並提供前後端開發工具。
前端拼裝層分爲二部分，基礎部分與 APIGW 對接，基於 VO 建模，可視化配置和綁定業務能力接口；拼裝部分基於可視化編輯器提供前端組件的積木式組裝。
後端能力層分爲二部分，基礎能力封裝業務核心代碼，用於快速構建基線能力；定製能力主要基於 SDK 進行定製開發，基於 SPI 擴展點，利用多態特性實現定製。
開發框架主要是提供 SDK（封裝註解及定義）方便定製開發、vs studio plugin 和 maven 插件用於打包發佈。
Runtime Infrastructure 包括 CICD、日誌、運行監控、自動化測試等能力。
一、研發過程管理平臺的架構設計方案
除了編碼採用線下開發（提供必要的 plugin、sdk，如果部署方式走 serverless，可以考慮集成 monaco 進行定製，實現線上 coding->compile->test->deploy 一體化），其它包括項目管理、需求管理、版本管理、工程管理均可在該平臺上集成並進行日常管理。同時，研發過程管理平臺還可通過對接前端開發平臺、後端開發平臺、CICD 平臺、質量管理平臺、帳戶體系形成一個完整的應用開發 studio。
二、前端業務組件拼裝的架構設計方案
裝修編輯器：提供支持相對佈局\絕對佈局的編輯器，提供包括頁面佈局調整、樣式調整、組件拖拽展示、預覽、屬性設置在內的所見即所得的功能體驗。
複用沉澱機制：前端拼裝的基本粒度是業務組件，能完成具體業務動作的，與後端能⼒連接的（可選）業務組件，⽽ ⾮交互 / 基礎組件。舉例來說，商品列表、購物車、買家訂單列表都是前端拼裝中的組件，⽽ Button 、Input 、Toast 等屬於基礎組件（Base Component），不是前端拼裝會操作的組件級別。版本發佈時，新開發或修改的組件經過 webpack 打包成 npm 包，上傳 npm 倉庫，用於下次開發複用。
業務流編輯器：用於描述前端組件之間關聯關係的編輯器（所謂關聯關係，目前可以淺顯地表現爲組件跳轉顯示關係，實際上由於每個業務組件都與後端 API 關聯，也代表了後端的調用流程），提供 4 種基礎概念元件，分別爲 Process、Branch、Begin、End，每個概念元件均可以綁定特定業務組件，在編輯器上將概念元件連線，然後通過組件內部實現的“出入口”機制，實現組件與組件之間的跳轉關係。
頁面管理：頁面在業務組件化的前端系統中，作爲業務組件的容器，承載佈局信息。
後端服務綁定：每個組件都能有選擇地綁定 1 到多個後端 API，當點擊該組件中某個控件的響應操作時，會觸發對後端 API 的調用。這樣的好處是，解決方案部署的同時複用了前後端的功能和體驗，可以快速生成原型或交付件。
同時，爲了提升開發體驗和效率，需要配套提供開發 SDK、集成開發環境的插件（vsc plugin 等）、以及包括配置、告警、監控、A/B Test 等在內的公共基礎能力。
三、後端開放性架構設計方案
由後端服務提供服務 SDK，前端組件通過該 SDK 對後端網關暴露的 API 進行綁定，事實上建立了業務組件與後端服務的關聯關係，這種綁定方式是去代碼化的，並且基於精巧設計的、對象化的、功能兼容的接口（例如 graphql）可以實現動態切換（免代碼修改）。
Domain Service（領域服務）通過對領域功能和流程進行抽象，提供基線（標準）功能，並對領域數據封裝原子級別的操作入口。
Business Service（業務服務 / 定製服務）基於 Domain Service 提供的擴展點（SPI）實現功能和流程的定製。
Domain 和 Business 可以實現完全的代碼隔離，這對於生態的知識產權保護非常關鍵。
DB 和數據訪問層主要作用是對 Domain 標準定義進行領域數據建模，同時針對業務提供數據建模的擴展能力，並且服務於 B 端，還需要充分考慮租戶間數據隔離和數據跨應用聯通的方案。
前端的開放性設計
前端的開放性設計涉及到 4 個維度：業務組件、沉澱與複用、業務流、組件的擴展。
組件業務化及跨平臺化
這裏的業務組件，如前面所述，是能夠觸發或完成一個業務動作、與後端能力連接的業務組件，⽽⾮交互 / 基礎組件。這樣，一個業務組件實際上封裝了端到端的邏輯（前端的操作、體驗，後端的功能、數據）。使用一個業務組件，實際上也使用了與其綁定的後端能力和數據
另外，由於 To B 市場在端側的多樣性，從成本的現實考慮，前端組件跨平臺的需求也非常常見，近幾年，由於 Electron、微信小程序、RN\Weex 等技術的成熟，類 html+css+js 已經成爲事實上跨多端的首選技術。
PC 端與 Mobile 端由於體驗的差異，組件往往不能共享，但通過一定的表現式語法抽象（suning DSL），通過提供 DSL parse sdk 對抽象語法解析，提供更高層次響應式的解釋和適配（如，在 PC 端可以解釋渲染爲 List，在 Mobile 端可以解釋渲染爲 ListView），可以在一定條件下實現 Write Once Run Anywhere。
沉澱與複用
前端工程在開發之初，定義 PRD（這種 PRD 是一種電子化的，可結構化定義並存儲的 PRD），並在平臺上創建解決方案。
複用：新迭代或新應用開發時，根據業務需求，可以到業務組件倉庫中尋找（類似於 AppStore），如果是已有且可複用能力，則由平臺直接添加 NPM 依賴到對應開發工程中，對於不具備的能力，標識爲 todo。
沉澱：當業務組件開發完成，通過在 CICD 平臺配置腳本，同時沉澱業務組件的 NPM 包，並更新 PRD，爲下次複用準備。
這種沉澱和複用機制，以業務功能維度進行，實現了代碼的完全隔離，並依賴平臺，可實現完全的自動化。
業務流
單獨對組件粒度進行復用依然會帶來不必要的重複工作量，同時組件間也需要⼀種機制進行串聯。頁面組是⼀種⽅式，將⼏個高度相關的頁面做成⼀個頁面組，彼此通過相對 url 串聯。但某些交叉頁面（例如商家後臺首頁）可能會是多個業務行爲的入口，包含多個業務組件，如果有關係的頁面都做成頁面組，那⼀個頁面組可能會包含很多個業務⾏爲；如果將這種交叉頁面從頁面組中拿掉，⼜會導致頁面組本身不完整；後臺系統較少交叉頁面，而前臺系統會有很多。所以通過定義業務流（操作流），並定義等價組件（Equivalent Component），來解決上面的問題，使分解⼀個站點成爲多個業務行爲並再組合成爲可能。
組件的擴展
首先，通常的業務組件，其邊界是模糊的，並且與應用頁面的緊密耦合，導致其無法被內聚實現，並進行復用。其原因主要有兩點：
1、應⽤內邏輯由 url 串聯，url 屬於應⽤全局的信息，但會出現在業務組件內部；
2、使⽤全局狀態管理，組件間共享狀態，但往往未經過良好 設計，導致組件間有隱式的互相依賴；
因此，需要將顯式的 url 從組件內移除，引入出口概念，組件自定義出口（行爲和參數），將出口行爲和出口目標分離，並提供業務組件級別的狀態管理，狀態可在業務組件內的繼承組件間共享，但不可以在業務組件間共享。
其次，由於組件具有業務屬性，而業務之間往往存在一種固有的流程機制（如加車 ->下單 ->支付），通常的方案，是建立一組 Page 的集合（Page Group），彼此通過相對 url 建立關聯。但某些 Page 包含多個業務行爲的入口（如首頁樓層），如果有關係的 Page 都做成 Page Group，那一個 Page Group 可能會包含很多個業務行爲，無法複用；如果將這種場景排除掉，又會導致方案本身的不完整。因此，基於頁面來複用這種業務關聯是不合適的（如前所說，Page 只是一種容器）如果建立一種串聯機制，可以動態地定義業務組件之間的關係，便可以脫離 Page 的限制，實現真正的解耦。
因此，可以引入業務流（操作流）的概念，動態地定義組件之間的關聯關係，使複雜業務關係的複用和重組成爲可能。
業務流（操作流）是一組具有關聯關係的業務組件的集合，通過數據結構定義組件之間的關聯關係，通過這種方式將業務流觸發條件和行爲封裝在操作流內部，不再受 UI 變化的影響，也就規避了以往頁面變化時，url 和調用方式需要重新實現的問題。
實現組件間跳轉的邏輯：
1、Component 描述出口方法和數據對象
2、在業務流（Business Unit）中獲取 SourceComponent 組件的出口 output 定義，執行 output 方法，命中 TargetComponent。
3、獲取 TargetComponent 所在的 Page，匹配 output 或 URL，設定跳轉方式，並執行跳轉。
最後，來講一下組件本身的擴展。
UI 的實時響應式擴展：依賴於 React\Vue\Angular 等響應式前端框架，利用組件的單向 / 雙向數據綁定能力，當組件的屬性發生變化時，VDOM 會對變更部分進行實時的局部渲染。利用這個特性，我們可以設計一種組件的 Setter 機制，這是一種屬性的注入器，利用 js 實現，當變更組件的某個屬性，比如背景色、分欄、圖片等，可以實時地對反饋到組件的展現部分。對於功能部分的擴展：可以對組件現有能力進行兼容或非兼容性升級，重新發布到線上，並通過組件更新機制來實現功能擴展。
後端的開放性設計
前端組件應對了業務場景化需求，但這個複用顆粒度對於業務邏輯和數據而言仍然比較粗，因爲即使是不同的場景，內部的邏輯和數據結構依然可以複用。而且，後端大都採用了微服務架構，各系統提供了原子接口，不同的原子接口匯聚成一個個標準業務流程，但在 To B 的生態中，定製與擴展的場景很常見，比如：
基線提供的業務流程，在交付給 A 和 B 的過程中，都有存在定製變更的可能性，當然，對於這種場景，可以通過在基線中做個功能全集，然後定義不同的業務參數或配置來開關，但還有些場景是開關和配置無法滿足的，比如互斥和擴展的場景：
這個時候，要麼拉分支自己改，但這樣做後續代碼分支多了很難合併收斂，增加運維成本；如果讓 ISV 和 SI 維護分支，又冒着核心代碼公開的風險。
因此，如果能設計一種靈活二開的後端開發框架，由 ISV 和 SI 根據業務定製需求進行擴展，便有了必要性。
架構和流程
將後端服務劃分爲：網關、業務定製層和基礎能力層。其中網關主要作用是對外暴露 API，Business 和 Domain 的服務都負責各自領域的業務建模，包括自己的元數據建模和視圖建模，Business 和 Domain 都對外提供服務，不同的是，Domain 提供提 SPI，是可複用、可擴展的點。而 Business 可以提供 SPI，也可以提供 API，視具備策略而定。
上圖是一個二開的示意流程，在每個變更點，添加待實現的 SPI，並在平臺結構化落庫。在網關上添加（新增）或修改（現有）API，指向該 SPI，此時，前端可以在平臺上查詢到該新增的 API。通過元數據建模和視圖建模，並結構化存儲到平臺上，前端可通過平臺查詢到視圖信息，根據視圖的 schema 可以進行前端開發。後端則實現該 SPI，並通過 CICD 發佈沉澱到平臺中，用於交付及後續複用。
SPI
SPI 是後端框架實現開發性設計的關鍵元素，它由服務的提供者來定義，確定命名空間、方法名、出入參，平臺上的 SPI 可以簡單對應到 java 世界中一個單方法的 interface。
Business 和 Domain 對外暴露 SPI（Business 可以暴露 API），通過對 SPI 定義、迭代、調度、複用和沉澱實現能力的開放。
註解：
@BusinessSPI 業務應用層 SPI 註解
@DomainSPI 領域中心層 SPI 註解
SPI 定義的步驟：
1、從平臺上創建的 git repo 上 clone 到可開發的 maven 工程
2、在工程目錄的對應目錄中編寫 spi 定義，並加上 @SPI 註解
3、命名工程中提供的 maven 插件打包，插件會將 spi 信息抽取並提交到平臺。
4、平臺會生成實際可用的 jar 併發布到 maven 倉庫，返回操作成功與否等信息，開發者可以在編譯打印中查看。
SPI 定義的示例：
通過定義 SPI 對外暴露各類可定製點，利用 java 的多態性，針對不同的業務場景定製不同的 Impl。在實際的使用中，框架還需要支持 version、多租戶等層面的信息，用於確保路由的正確性。
目前的二開，主要是通過 SPI 的機制，在現有產品和解決方案的 Domain 能力基礎上進行覆寫或擴展，實際使用中，可能存在以下幾種情況：
1、給定的 SPI 抽象準確，現有的實現代碼滿足要求，則直接使用現有鏡像。
2、給定的 SPI 抽象準確，現有的實現無法滿足要求，則重寫一個新實現。
3、給定的 SPI 抽象不準確，邏輯無法滿足要求，則定義一個新的 SPI 並實現。實際使用場景中，@註解還可以細分成多種：
1）命令式申明註解 @BusinessCMDSPI、@DomainCMDSPI
2）查詢式申明註解 @BusinessQuerySPI、@DomainQuerySPI
元數據
元數據提供 @Entity 註解來申明定義。
元數據不支持嵌套（主要是因爲複雜，同時不是必要），一個 Entity 內部的成員變量不能是 Entity。
元數據參數存儲上支持字段擴展，採用屬性值表設計，原來應用配置的數據源會退化爲元數據後端的地址；元數據後端提供視圖映射功能，可以針對元數據直接做聚合查詢，並直接生成 SPI 及對應 SPI 的實現代碼。
Entity 定義後實際可能會映射到多張物理表，整體方案從技術上來說，主要難度在於事務處理上，目前來看短期內沒法構建一套可靠穩定的方案，因此，操作內部實現目前走 mapper 並直連數據源，但對外暴露統一的 load/save 方法。
定義及沉澱流程：
1、開發時，定義 Entity 並申明 @Entity 註解，通過 IDE 插件解析註解，將本地元數據定義 DSL Push 到平臺服務，平臺根據定義自動識別變更、合法性，生成物理庫表。
2、IDE 插件提供一套類似 lombok 的編譯器修改抽象語法樹的機制，給元數據提供 load/save 等方法。
3、增加元數據 save 擴展點方便 handle 業務代碼插入。
4、運行時，具體的 load 和 save 方法會調用元數據後端提供的 RPC 服務。
5、發佈時，元數據地根據 Application+ 類名，並變更自動生成的版本號。
視圖
在 To B 的應用中，表單和列表佔據半壁江山，可以針對典型的中後臺應用表單進行抽象，輸出一份通用 scheme，基於該 scheme 進行視圖建模。
業務上很多場景化查詢需求，如果這部分實現全部落到 Domain 層，對 Domain 層的穩定性是個衝擊，視圖建模和視圖查詢主要應對這些場景。
在後端平臺側提供視圖建模功能，可以自由搜索元數據，選擇需要的字段，組合成新的視圖，開發人員需要給出元數據字段到視圖字段的 mapping 關係，以及指定視圖的 id 作爲唯一標識，並進行發佈。
發佈後，平臺自動生成對應的 @BusinessSPI 或 @BusinessQuerySPI 定義和實現，package 成 jar，並 Push 到 maven，對應視圖的查詢和簡單的 CRUD 結果集便可自動生成。
如果修改視圖，在平臺上修改視圖字段，平臺重新生成相關的查詢 SPI 和實現，並自動變更視圖 version。
在視圖關聯數據庫方面，如果採用的是物理庫表，則可能會出現一個視圖對應關聯多個庫表聯合查詢的情況，這個邏輯比較複雜，考慮了 2 種方案：
1、落到 es 進行查詢，走 mysql->canal->es 的方案
2、走邏輯大寬表方案
前後端的銜接設計
同步 VO 與根據 VO 獲取數據進行分離，由 API GW 進行解耦，通過視圖 id 或 name 進行數據操作。前端通過特定接口獲取到該應用的所有 vo，並進行列表展現。每個 vo 都有對應的 version，用於同步 VO 的變更。
前端平臺提供 loader 或 parser 解析視圖 VO，反向渲染生成組件。
後端平臺通過搜索元數據，選擇需要的字段，組合成新的數據視圖 -DO，後端平臺自動生成對應的 @BusinessSPI 或 @BusinessQuerySPI 定義和實現，package 成 jar，並 Push 到 maven，開發本地應用。（對於某些 VO 和 DO 直接一對一映射的場景，前端也可以考慮直接使用 DO）
根據上圖，開發平臺的基本流程和各層功能爲：
1、基本流程：數據對象 DO->SPI->API->展現視圖 VO->組件 ->UI，前端業務組件直接與後端 SPI 及數據對象進行映射。
2、前端拼裝：
1) 提供編輯器，支持絕對佈局和相對佈局，可以由 VO 直接生成業務組件；也可以採用類 Axure 手工拼裝成組件，並綁定後端 API。
2) 支持基於現有業務組件，通過業務流（操作流）和 Setter 機制來擴展組件能力。
3、後端能力：在 Business 和 Domain 都支持通過 SPI 來定義服務的擴展點，ISV 和 SI 可以在不修改原有邏輯的基礎上，通過替換 SPI 來實現功能的替換、升級和擴展。
4、數據層面：通過將前端組件與後端 SPI 及數據對象進行映射，若對元數據對象進行新增或變更時：
1）可以直接動態變更 UI 的展現形式和內容，無須修改前後端代碼
2）通過定義數據視圖，能夠根據業務訴求，對不同元數據進行聚類、組合、以實現運算的目的，同時能夠以不同的組件形式對後端數據進行展現
結語
從雲計算的發展趨勢來看，從 Iaas 開始，未來必將在 Saas 結束（Paas 因爲包括各種標準化組織和開源社區的存在，未來少有溢價的可能）。而 Saas 也是議價空間和增值空間最多的地方，未來哪家企業能夠首先完成對各個行業和領域的在覈心生產流程和業務抽象，整合更多更優秀的 ISV 和 SI 資源、甚至社區的力量，誰就能成爲事實上的標準。
對於 To B 領域的玩家，應該走開放生態的道路，做生態，就是做標準；做平臺，就是做信任；做開放，就是做共贏。
作者介紹
榮多君，蘇寧科技集團 O2O 平臺研發中心副總監，多年 ICT 及互聯網工作經驗，曾先後就職於華爲、阿里巴巴，現在蘇寧從事 O2O 新零售業務及平臺的建設，擅長前後端主流技術、移動互聯網平臺建設及服務治理、雲原生及中臺技術。