?一、引言

組裝式應用程序是Gartner在《2022年重要戰略技術趨勢》中提出的十二項技術之一，主要是通過引入模塊化的PBC使技術和業務團隊可以更敏捷、更有效地重用代碼。那么PBC是什么？

業務能力包(PBC)是一種軟件定義的最小化的業務功能，專注于解決特定的業務問題。業務用戶在功能上可識別這些功能，旨在用于應用程序產品套件和自定義組裝應用程序體驗的構建基塊。PBC是數據架構和一組服務、API和事件通道的有界集合，可以被視為微服務的聚合,在功能上是完整、自治的體系，具有四大特性。

• 模塊化：分成一組有凝聚力的組件。
• 自主性：自給自足，并具有最小的依賴性，以確保組成的靈活性。
• 編排式：通過 API、事件接口或其他技術手段，打包組合到流程流程或復雜事務中。
• 可發現：語義清晰和經濟的設計，使業務和技術設計者、開發者和活躍的應用程序都能訪問。

其中在編排式上，圍繞PBC和它的編排能力，帶來的問題就是我們本次特別引出的組裝式。從圖中可以看出原來有三個不同顏色的PBC，我們通過一定的方式對這三個PBC進行組裝從而形成一個新的應用，從而對外提供能力。

Gartner表示：“在動蕩的時代，可組合的業務原則幫助企業機構駕馭對業務韌性和增長至關重要的加速變化?？山M合的應用架構增強了業務適應性，而采用可組合方法的企業機構在新功能的實現速度上將比競爭對手快80%。”

在這個組裝過程中，必然有很多問題需要我們去探索和實踐：

• 如何組裝？
• 組裝的標準是什么？
• 組裝時是否會存在一些安全風險？
• ……

那么我行當時在建設的時候，為什么會對標組裝式應用程序，是如何引進這個概念并且落地實施的？圍繞這個問題，首先介紹我行當時在建設時面臨的問題。

我行近幾年在大力建設金融生態場景，對外提供了很多SaaS應用，這一部分除了我行自建之外，我們也會與一些合作方進行合作。隨著無界融合、優勢互補、開放共贏的金融生態圈的不斷發展，我行在面對客戶快速推出生態產品、提供一站式解決方案方面存在一定不足，以支撐應用組裝式開發方面有待提升，總結起來主要有以下四個方面的能力欠缺，分為技術和管理兩個部分：

技術上：

1）生態融合

缺乏統一的產品目錄和產品能力，沒有形成市場化的建設；

生態缺乏通用的基礎服務，如用戶、權限、流程、數據訪問能力和用戶交互界面。

2）場景復用

非金融功能重復建設，獨立研發，缺乏場景級能力輸出；

金融功能存在各場景重復封裝。

管理上：

3）標準技術建設方案

生態建設統一標準有待完善，功能耦合度高，無法實現能力復用，導致重復造輪子，應用搭建效率低；

新場景建設需求日益頻繁，缺乏基于既有場景快速組裝能力的支撐。

4）統一管理運營

缺乏功能場景、共享服務標準、數據標準的統一管理標準；

缺乏生態場景級的可復用基礎框架、構件需求管理。

當時我們面對SaaS產品的建設中主要存在剛才提到的這些問題，未來我們如果還要更快速地發展，更快速地推出產品，我們必須針對問題提出一些解決方案。因此我們圍繞這些問題對標業界，發現組裝式開發在技術和業務方面都有一定的優勢，能夠快速組裝現有的業務能力，推出一個新的應用產品，最終我們選擇了組裝式應用程序開發落地。

二、生態連接器建設

接下來介紹我們的生態連接器建設，這是我們當時在落地的時候形成的總體架構圖：

1、建設通用基礎服務

我們需要做一些生態融合，解決組裝的能力問題，其實就是要建設好通用的基礎能力。實現通用用戶、權限、角色、機構、流程管理等基礎服務，提供數據共享訪問，打通生態產品場景融合。

在基礎能力方面，用戶中心、權限管理和流程管理是比較基礎的，以及用戶菜單、角色、機構等，基本上我們的每個SaaS應用建設時都會涉及，包括與行外合作方提供的SaaS應用進行融合的時候，都必須包含流程管理等基礎能力，這一方面是作為融合能力重點建設。

2、建設業務共享服務標準化輸出能力

在融合的過程中，我們需要提煉一些共性的業務共享服務(PBC)，類似于前幾年提的中臺，比如資金監管、項目中心、流程中心，并且圍繞這些能力支持PBC建設的配置化，比如樣式的自動適配、數據標準，以及快速組裝，我們也會專門制定一套數據共享的訪問，從而解決各個上市產品之間數據共享，以及數據共享中存在的安全問題和標準問題，實現數據標準化轉換和打通，實現產品場景的快速組裝能力和標準化能力。

3、提供研發支持基礎框架

在融合的基礎之上，從架構的分層來看，最底下就是提供基礎的技術能力支撐平臺，建立產品組裝平臺快速構筑產品，以及一些技術標準框架，類似于我們業界熟知的Spring Boot，我們可能也會在上面做一定的封裝，形成適合我們應用的框架內容。

有了這些PBC的業務能力之后，我們會面向不同生態場景，比如當前國家在推廣鄉村振興，那么在這一方面我們也會推出一些對應的SaaS產品供鄉村使用。

在生態場景的概念之上，我們額外提出了一個生態解決方案。從客戶角度來說，比如鄉村振興的生態場景，除了管理村里的一些事務之外，可能也需要黨員管理，從技術層面我們關注的是場景和應用，但對于客戶而言，他關注的是功能和能力。未來我們會更進一步，面向不同的群體提供一些生態解決方案，比如智慧教育、智慧政務、新管家等。

借助于組裝式應用程序開發理念，我們層層往上，通過不同的PBC形成一個新的生態場景，再通過不同的生態場景形成一個新的生態解決方案，從而打造生態場景融合能力+業務共享服務輸出+技術標準能力支撐，并配套完整的生態管理體系，實現生態場景快速建設，提供端到端統一服務的目標，這是我們的生態連接器上的總體建設。

三、業務服務包(PBC)落地

從業務能力上來說，核心在于PBC的建設，所以著重再跟大家分享一下我們PBC落地的架構層面和設計層面上的規劃，從外部市場也就是客戶的視角梳理一些場景。

我行做得比較多的是一些金融的場景，對于我們來說，我們的概念中更多區分的也是金融和非金融，但其它一些企業在落地的時候，可能會有其它劃分類型。

我行提供的金融服務是比較豐富的，代收、支付、賬戶管理、資金監管，都是銀行傳統的優勢方面內容，然后我們重新整合形成共享服務包，為后面的產品快速上線提供支撐。

生態場景的不斷豐富，也帶來了一些新的非金融服務能力，我們將其劃分為通用領域和專用領域。

通用領域即基本上每個領域都能用到的，比如流程中心、積分管理。從客戶服務的角度分析，基本上都會設置積分，所以我們將積分管理設置為通用領域。

專用領域則是面向于特定的某一類場景或解決方案，將共性的內容抽取出來。

在具體實施的時候，我們也是對標組裝式應用開發和PBC的概念，支持“模塊化、自主性、可發現、可配置”，其實關鍵點在于支持數據標準轉換和對外統一標準的服務輸出，包括統一數據字段、統一接口標準、統一UI風格轉化。

尤其是UI風格方面，我們所說的統一UI風格，指的是統一UI風格的設計理念。面向不同的客戶提供的SaaS產品，客戶在UI風格上可能會有不同的需求，比如黨建方面則是紅色的顏色會偏多一些。同一個共享服務包，需要支持面向不同的客戶群體和SaaS產品能通過統一的UI風格進行適配。在最底層我們的技術細節實現的時候，也會支撐統一的數據字段、數據標準的轉化。如果共享服務包在組裝的時候缺少了一套統一的標準，那么組裝的時候必然會存在一些問題。

我們對于PBC落地的技術要求和管理要求如下：

1、技術要求

配置能力暴露：暴露菜單、頁面UI配置接口，在產品復用業務時初始化設置菜單、實現UI配置等配置功能的設置和初始化。

應用接口暴露：根據DDD思路對共享服務抽取接口，形成場景化的業務能力組合，并在組裝平臺進行發現。

對外輸出：支持轉換為開發態的業務組件，提供行外獨立部署。

2、管理要求

開展牽頭應用承建機制：由領域負責應用承接進行建設，按照單獨建設群組方式進行共享。

場景建設：在智慧教育、鄉村振興、政務等重點戰略重點突破，形成相關領域的業務能力包。

四、組裝式應用開發

圍繞業務服務包的建設，我們當時也對標了組裝式應用開發的理念。

1、金融生態應用組裝平臺

我們規劃建設了一個金融生態應用組裝平臺，平臺主要分為三個部分：

首先是元數據目錄，比如數據編排、數據標準和數據的動態集成，未來可能還有知識圖譜等概念做一些基礎的支撐；

元數據目錄再上一層是應用模板，面向不同的場景，我們需要制定出不同的應用模板；

最上層是可視化建設，針對不同模板下的業務服務包(PBC)進行組裝，同時也有支撐PBC建設的技術組件，通過平臺自由組裝。

通過這三層實現增量功能，包括增量產品、存量產品的快速生產，對于新產品可以通過組裝快速生成整個應用，存量則更多考慮如何兼容和升級。

2、DDD設計思路

在實際落地開發的時候，對于PBC如何劃分，內部提供了什么能力等問題，需要一套方法論支撐。業界上近幾年微服務比較熱門，DDD的思路也是用得比較多的，我們行內有一套業務建模的方法與DDD是相通的，通過建模梳理出了PBC的一些能力。第二步就是生成PBC，因為組裝是一個積木的概念，所以需要先生成積木，再組裝積木，最后生成一個完整的工程。

在業務建模方面，我們采用DDD設計思路，在架構層面引入六邊形架構。因為我們在建設的時候，傳統的應用會有一些分層的概念，但是代碼可能會串層，發生邏輯的上移或下移，我們通過六邊形架構詮釋應用內部和外部差別，內外部通過適配器交互進行隔離，內部聚焦領域服務，從而實現穩態領域層和適配層解耦。

從上圖可以看出，我們在原始的六邊形架構上做了一些延伸，也就是6個標紅的部分。我們在落地這套領域驅動設計的架構時，領域層聚焦于領域模型對象、領域服務、應用服務的設計和組合。相當于在業務建模的時候，會識別出來有哪些領域對象，圍繞著這些對象會有哪些服務和應用，這是最核心的內容。

對象工廠、領域事件和倉儲，我們的理解一定程度上是屬于技術實現，在技術實現上，通過面向對象的設計以及設計模式的引入，在對象創建、對象交互上達到靈活解耦。

對象工廠用于創建對象；

領域事件用于對象之間的信息交互和解耦；

倉儲用于數據交換，比如我們在落地時，需要引入一些存量應用，一個實體可能對應到多張表，多張表則需要做一些拆分和整合，因此在倉儲上會做一些額外的工作內容。

針對這套DDD標準架構的落地，我們會有一個標準工程結構，明確工程結構設計，設計者可以和代碼閱讀者交流領域和架構的設計意圖。圍繞這套工程建設，我們也有一套配套的工具支撐，總結標準應用結構生成、依賴檢查工具、標準資產組件/工具推薦等，一系列工具資產保證架構落地。

接下來我們通過一個例子介紹DDD的設計思路落地。其實DDD最核心的是一些聚合根和實體對象的抽取。我們行內有一套就是業務建模方法與DDD理論一脈相承，DDD里的事件風暴我們行內稱為業務用例，就是通過一段話與業務人員討論業務場景和業務能力。主要流程如下：

首先找一些名詞，給這些名詞加上屬性，通過名詞之間的關系形成一個實體領域模型，我們稱為業務對象；

其次將實體對象進行聚合形成一個聚合根；

最后圍繞這些實體模型找一些相關的動作，如支付、提交，從而形成領域服務、交易服務等能力。

以某代理保險銷售應用為例：抽取保險協議的實體和值對象，做抽象類的聚合和設計。實體分為財險保單和壽險保單兩大類，值對象指的是保單上的各種屬性，包括產品信息、公司信息、保單期限、費率信息等。未來我們在值對象設計上可能會做一些技術手段，通過定制手段自動化地動態展示前臺頁面等，形成了整個聚合根和實體的值對象，從事件風暴來講，也就是梳理出用例，再進行組裝式的開發。

3、低代碼能力

組裝式開發離不開近幾年一直在談的低代碼能力，我們也是通過低代碼能力進行落地實踐。

采用低代碼能力，生成代碼符合標準工程代碼結構，應用可自定義連接不同數據實體，基于實體自動生成對應的領域服務等相關PBC積木塊內容，同是針對多實體聚合可復用DDD設計的聚合根對象預先在數據庫創建虛擬實體從而自動生成。自動生成有以下幾點需要注意：

我們傳統針對表，實體可能是get、set方法，在DDD領域里其實是貧血模型，未來我們設計一種充血模型，也就是實體還是會帶一些方法，我們現在已經能夠比較好地支持針對于實體的增刪改查的能力，圍繞實體生成對象服務。

我們在選中實體生成代碼時，可以進行一定的定制，在增刪改查的基礎上，我們平臺會更多提供擴展能力的支持，比如聚合，平臺通過類似于DSL等一些腳本的能力對其進行定制，讀取我們定制的一些內容，自動生成這一部分代碼。

除了對象服務之外，圍繞實體也可能會有一些簡單的領域服務，也就是圖中標的業務服務，另外，我們行內在單元測試方面也是落地比較深的，因此所有代碼我們都必須有對應的單元測試覆蓋。我們目前生成的單元測試符合行業要求，生成單元測試之后也是按照標準代碼結構生成代碼，圖中示例是以某應用中產品信息實體為例。

針對實體對象生成的能力，比如增刪改查，我們抽取了多個應用進行分析，以某應用為例，應用中涉及80多張表（占比30%）可以一次性通過低代碼平臺直接生成，加速研發效率，剩下的可能需要額外進行組裝和定制再生成。

至此我們已經通過建模建出實體對象，也通過低代碼方式自動生成了圍繞這些實體對象的一些基礎能力，這一部分能力就是我們之前提到的積木。

4、組裝

有了積木塊建設之后，我們接下來要進行的是積木塊的組裝，這一部分也是通過組裝式應用開發平臺完成。

1）整體設計

基于組裝式應用開發平臺，遵循“積木式”開發思想，按分層結構去做，通過日益豐富的技術積木塊和業務積木塊的靈活組裝，助力應用快速搭建應用基礎框架。

自動生成代碼符合標準化目錄指引和包命名規則，從架構設計到代碼生成是標準的一一對應關系，統一項目研發，引導開發人員踐行DDD模式。

根據清晰的工程目錄覆蓋對象設計的不同能力，形成穩態和敏態的有效區分，隔離圍繞對象自身的建設和對業務場景的建設，進一步展現圍繞對象開展系統建設的邏輯視圖。

2）業務組件編排

整體設計完之后，通過業務組件編排進行積木組裝，這一方面與低代碼能力也是息息相關的。業務組件編排基于低代碼能力生成的對象服務和業務服務進行自由組裝，可實現對象服務組裝生成新業務服務，也可支持業務服務組裝生成交易服務。

上圖的左側就是我們針對業務積木的組裝，業務積木塊有不同的分類，比如保險、教培等，同時權限中心、流程中心、認證中心等基礎能力也包含在目錄里，按一級、二級不同的目錄結構提供選擇。我們的技術人員要組裝成一個服務能力時，即可通過該平臺進行一些邏輯關系的組裝，比如可以在每條線上制定一些表達式條件，當某個值等于多少時則往哪個分支去做，從而通過組裝重新形成新的服務，完成對整個PBC內部的一些能力建設，形成一個新的PBC對外提供能力。

在目錄建設的時候，我們按照不同的PBC劃分模塊化，生成的服務采用模塊化開發思想進行組織，不同的服務聚合于不同的物理目錄下作為子工程存在，各服務子工程可獨立開發。不同的人或團隊能夠各自管理和維護各自的PBC能力，從IT架構指導組織架構調優，進一步提升開發解耦。

3）技術組件編排

技術組件編排通過對接已有技術能力，支持基礎能力以及技術組件的快速組裝。行內通過共建形成了一套標準的技術組件，可以將建設好的技術組件直接引入平臺，令大家自行選擇需要的組件和能力，從而為整個PBC的建設包括應用建設形成組裝。

5、生成應用工程

完成業務和技術的組裝之后，最后一步是生成整個應用工程。

1）首先是一站式生成應用基礎框架，統一一站式技術底座，大大提升應用工程搭建效率。我們引進了多套模板，如DDD、分層架構等，不斷豐富應用基礎框架，同時針對不同的節點梳理它們不同的能力，從而通過組裝平臺生成不同的節點的標準工程，如接入層節點則是路由、灰度、限流比較重要，批量的數據處理則進行文件導入導出的一些技術構件。

2）一鍵快速運維能力接入，解決運維能力使用的最后一公里。平臺所提供10余種生產運維組件包括應用監控、自隔離、人機密碼分離等基礎運維能力，自動集成應用的一些能力建設，避免重復造輪子。

3）對標云原生能力，自動生成PaaS鏡像模板，解決了PaaS鏡像不同環境變量配置的問題，實現了PaaS鏡像模板制定從數天到分鐘級的跨越，大大提升上云效率。

在Gartner提出的PBC如何組裝建設的基礎之上，我們對于PBC內部如何聚焦、組裝和建設做了更多更深層次的延伸，不只PBC間實現組裝，在PBC內建設時也支持組裝式開發。

五、未來展望

1、標準能力

在實現行內PBC以及未來行外合作方PBC接入后，實現PBC之間的組裝需要制定一套標準的組裝規范，統一組裝能力，中國信通院也在今年7月份提出組裝式應用開發，并組織相關企業準備制定相應規范，我行也將擇機參與，以便融入行業生態，將著重從以下五方面推進：

通用能力：包括我們的通用工程、標準工程以及標準集成的一些能力，在落地時針對細分的不同類型制定不同的標準工程會更加精細化；

性能：生成的代碼是否存在性能問題；

安全：代碼生成是否安全；

適配：在標準工程生成時，比如Web節點上的XSS攻擊，能夠自動集成防XSS等的組件，進行頁面適配或組裝適配；

代碼：代碼的自研能力，以及低代碼生成能力。

2、數據共享、數據標準、數據血緣

數據共享： PBC之間的一些銜接、交互；

數據標準：數據共享如何制定標準，我們是通過單獨的SDK包內部做一些數據共享的標準檢驗、安全管控等內容；

數據血緣：未來規劃要做數據血緣關系的分析，也就是將完成PBC組裝的數據共享和銜接之后的最終數據做一些大數據分析，在這個基礎上探索做數據血緣關系的分析，從而為后面SaaS產品的數據運營方面提供一些指導工作。

Q&A

Q1：落地組裝式應用程序技術需要先落地DDD嗎？

A1：從微服務角度，以及我們PBC建設的一些劃分、識別來說，DDD這套方法論對于通過DDD建模建出來的一些實體的歸屬劃分關系非常契合，因此我們認為先落地DDD再落地組裝式應用程序技術會更便捷。

Q2：什么類型的企業適合落地組裝式應用程序？

A2：這個問題的本質就是組裝式應用程序技術的提出是為了解決什么問題。Gartner當時提出這項技術，以及我們國內一些大廠在落地這方面內容時，核心就是在業務快速發展、企業環境急劇變化的情況下，如何快速提供新能力和組裝新產品。因此如果企業想要快速搶占市場，或者業務變化比較頻繁，那么就適合落地組裝式應用程序。

作者介紹

張建榮：大型銀行 軟件開發中心高級經理

資深架構師，杭州研發部領域專家，負責技術管理、架構轉型等相關工作。2007年加入大型銀行軟件開發中心，致力于推動技術創新、效能提升，實現業務價值的高質量快速交付；先后牽頭信貸、票據、養老金、智慧政法等產品線和數字生態基座（組裝式應用程序Composable Applications）等多個大型系統建設；并作為技術專家，為安全生產提供技術支持。