大型商業銀行主機架構轉型DDD實踐

網際網路資訊科技發展日新月異，在開源分享的技術浪潮推動下，雲原生開放平臺體系越發完善與強大，傳統金融行業在大機系統封閉的技術體系下難以共享當代技術發展紅利，為保持行業競爭力，給使用者提供更優的產品體驗，銀行系統主機架構轉型工作刻不容緩。

工商銀行核心系統的功能完備性與穩定性在業界領先，擁有專業高效的業務功能開發團隊與基礎設施建設團隊。但業務規則與業務流程經過長年累月的需求研發更迭，處理邏輯日趨複雜，如何在行內企業級業務架構建模方法論的指導下，平穩進行主機架構轉型，設計出一個能夠產生持久增量價值的系統架構，是工商銀行軟體開發中心的行動價值與歷史使命。

挖痛點

銀行系統大部分業務場景繁雜且業務流程長，以某支付系統收報場景為例：一筆支付類報文包含最多兩千筆匯款明細，需要涵蓋行內十餘種賬戶型別、幾十種業務種類的賬務處理，支援關聯產品的識別與相關處理，當無法自動記賬時需要支援確認記賬、轉錯賬、轉退匯、轉轄內網點等功能。複雜的業務設計需要有統一標準的業務分析與設計方法，指導設計人員開展詳細設計。

從主機單體架構到平臺分散式架構，從程式導向設計開發到物件導向設計開發，需要一種建立在物件導向基礎上的系統方法學，需要有一系列已被實踐證明行之有效的成熟設計開發模式進行借鑑與參考，幫助我們從主機還原業務全貌，經過理順脈絡、清除雜質後，再對映到平臺實現。

分散式平臺系統建設，除了考慮系統的高效能、高可用與高安全，還要兼顧業務模型可理解性、業務功能可擴充套件性，如何隔離技術與業務的關注點，如何應對複雜多變的業務需求，如何防止架構和程式碼的腐化等問題，需要找到應對之策。

覓良方

DDD領域驅動設計是自成體系的一套軟體研發方法論，涵蓋了軟體開發的全生命週期，已經被大量實踐證明能夠有效應對軟體業務複雜性，透過拆解業務、歸類業務與劃分業務邊界，解決複雜業務系統難以理解、難以演進的問題。

一方面，DDD與現在工商銀行軟體開發中心分散式平臺微服務架構高度契合，與中心應用架構“物件導向”的核心設計理念相符。目標均為構建橫向可解耦、縱向有層次的軟體系統架構。業務建模可承接我行ECOS的方法論成果，有助於一線設計開發人員更好地理解中心的元件化研發方法，並直接使用相關流程模型與實體模型，是ECOS元件化研發方法的延續性提升，是對程式設計的深化指導。

另一方面，DDD有較為詳盡的落地方法論，在前期理論學習與小範圍實踐的基礎上，邀請外部師資進行案例培訓，參考老師推薦的方法，摸索整理出適合自身業務系統特點的領域驅動設計統一過程。

塑輪廓

提煉統一語言。統一語言是提煉領域知識的產出物，獲得統一語言就是需求分析的過程。形成統一的領域術語，團隊的統一語言是溝通能夠達成一致的前提。在前期需求分析整理階段，我們有意識地收集研究目標系統涉及的相關概念和術語，與業務專家深入討論並給出明確定義，統一指定中英文命名，確保業務專家、設計人員與開發人員對這些概念和術語的認知保持一致，並在後續的文件、程式碼與資料結構等輸出物中使用統一語言。

在專案前期梳理全量場景檢視，主要包括兩類，一類是端到端具有完整業務價值，可單獨部署上線的需求項;另一類是角色向目標系統發起請求，跟目標系統一次完整互動的需求條目。透過對完整需求項的拆分，我們系統性梳理了系統業務全貌，需求項為後續的需求池規劃、里程碑設定、工作量評估提供了資料支撐，也是後續研發、交付與投產的最小單元。透過對每個需求項下需求條目的梳理，針對性地深入理解系統的每個業務功能，需求條目為後續系統業務服務的設計、抽象與擴充套件提供了分析依據，同時也作為我們開發測試任務拆分的基本單位。

構骨架

DDD可擴充套件架構的基本思想就是拆，多維度對系統進行拆解，將整體分解相對獨立的部分，將每個部分的複雜度控制在一定範圍內。把目標系統切分成不同的部分，由不同的開發團隊來完成這些分工，並透過建立不同部分相互溝通的機制，使得這些部分能夠有機結合為一個整體，並完成這個整體所需要的所有活動。

1.垂直拆分——面向業務服務拆。按業務的自然邊界拆分限界上下文，根據最小完備、獨立進化、自我履行與穩定空間自治單元的拆分原則進行拆分，各個限界上下文體現了相應領域模型的知識語境，具有獨立提供業務功能的能力。不同限界上下文充分解耦、邊界清晰、職責明確、粒度可控，可以將每個上下文分配給獨立的開發團隊維護。

2.水平拆分——面向流程拆。對於一個大型的複雜業務系統，遵循關注點分離原則對其進行分解總是最為有效地降低複雜度的手段，我們參考菱形對稱架構做系統分層，該分層架構結合了DDD經典分層架構理論與整潔架構思想，形成了以領域為軸心的內外分層對稱結構(見圖1)。

圖1 菱形對稱架構圖

北向閘道器包含了遠端服務層跟應用服務層，提供了由外到內的訪問通道。遠端服務主要功能是為外部呼叫者提供服務契約，應用服務層的主要功能是定義要完成任務，編排表達領域概念的領域服務來解決問題。北向閘道器的一項重要任務是封裝好領域模型物件，避免內部領域模型洩露，做好外部訊息契約模型與內部領域模型的轉換。

領域層包含業務領域的資訊，是業務實現的核心所在，我們使用DDD戰術設計的實體(ENTITY)、值物件(VALUE OBJECT)、聚合(AGGREGATE)、資源庫/倉儲(REPOSITORY)等元素所構造的領域模型，透過識別提煉可共享複用的領域服務，提供公共業務支撐能力。

南向閘道器包含埠與介面卡，負責封裝領域層對外部資源的訪問，透過埠將領域層對於外部資源的絕對依賴轉換為對相關能力的絕對依賴，執行時系統透過依賴將具體實現的介面卡注入，提供相關能力滿足領域邏輯對外部資源的訪問需求。

菱形對稱架構遵循穩定依賴原則，依賴方向從外部指向內部，保障了領域模型更加穩定與純粹，隔離了外部變化的影響，不會因為外部服務契約的變化或者外部資源的變化導致業務程式碼修改。

3.核心拆分——面向功能拆。在拆分了限界上下文之後，會發現不同限界上下文存在著通用的功能，如機構某個清算系統的收發報許可權檢查、某個業務系統狀態檢查、渠道日誌登記等功能，為避免重複建設與保持相關功能實現的一致性，我們識別通用的業務功能並封裝為合適粒度的構件，將那些會同時修改，並且為相同目的而修改的類放到同一個構件中。在滿足功能複用的前提下，最大程度地精簡構件，避免不必要的依賴。業務構件以庫的形式被其他的限界上下文複用，遵循專案組內部制定的版本升級策略與升級操作規範。

業務構件將業務中可以共享的基礎服務能力封裝為業務構件，進行層層“沉澱”，共享範圍越廣的，沉澱得越深，實現通用業務服務能力的“分層複用”，起到隔離關注點的作用。各業務叢集功能開發人員無需瞭解通用核心實現細節，只需關注自身業務邏輯處理。

活細胞

經過以上步驟之後，我們已經擁有一個將業務邏輯層置於最高層次的穩定架構，業務邏輯程式碼成為系統中最獨立、複用性最高的程式碼，它保持純淨，不摻雜輸入輸出或基礎設施相關的東西。接下來我們即可專注於業務邏輯分析與設計。基於“塑輪廓”步驟得到的系統全量需求項，在這個步驟逐個進行分析建模與設計建模。

1.分析建模——業務服務規約梳理。針對需求項進行業務活動分析，梳理業務活動過程中目標系統對外提供的功能作為需求條目清單，需求條目一一對映為目標系統對外提供的業務服務，以業務服務為單位開展業務服務規約編寫，規約內容包括名稱、願景描述、觸發條件、驗收標準、基本流程與替代流程。

業務服務作為每個迭代週期開發交付測試的基本單位，測試根據觸發條件發起呼叫，根據驗收標準編寫詳細的驗收案例，檢驗業務服務是否滿足功能願景描述。

2.分析建模——領域分析建模。使用快速建模法建立領域分析模型。根據業務服務規約，識別出相關名詞，檢查這些名詞是否符合統一語言，對映為領域類。識別出相關動詞，判斷每個動詞對應的領域行為是否有產生過程資料，如有則可將該過程資料對映為領域類。

透過名詞和動詞識別領域模型之後，需要對這些概念做歸納和抽象，整理領域物件列表，並分析與標記領域物件之間的關係。

3.設計建模——聚合設計。分辨分析模型中的領域類是實體或值物件，將值物件放入它所依附的實體類中。進一步分析實體類之間的關係，明確它們的關係是泛化、關聯(一對一或一對多)、依賴還是沒關係，得到清晰的實體物件關係圖，並能直觀地瞭解各個實體類之間關係的強弱。

對關係薄弱處進行分解，得到初步的聚合邊界，根據完整性、獨立性、不變性與一致性的聚合設計原則對聚合邊界進行調整校正，得到合理粒度的聚合。去除聚合內部非聚合根實體與外部的關係，確保聚合之間只能透過聚合根相互訪問，降低領域類之間耦合的強度。

4.設計建模——服務驅動設計。根據業務服務規約梳理的業務基本流程步驟，將業務服務分解為多個任務，這些任務就是支撐服務價值的業務功能。當任務不需再分時，則對應具體的功能實現(見圖2)。

圖2 任務分解

任務分解完成之後進行職責分配，將任務按照以下原則分配給DDD戰術設計的各類元模型設計要素，組合任務分配給領域服務，無外部資源依賴的原子任務分配給聚合，依賴資料庫訪問的原子任務分配給資源庫埠，依賴外部服務訪問的原子任務分配給客戶端埠，依賴事件匯流排的原子服務分配給訊息佇列釋出者埠(見圖3)。

圖3 職責分配

5.實現建模——測試驅動開發。使用UTDD(單元測試驅動開發)進行組合任務與原子任務程式碼開發，任務經過分解與職責分配後明確為具體類的方法，根據每個任務的業務功能編寫測試用例，然後按照“測試—開發—重構”的節奏開始編碼實現，逐個完成所有任務的開發。

使用ATDD(驗收測試驅動開發)進行應用服務開發，根據業務服務驗收標準編寫測試用例，同樣按照“測試—開發—重構”的節奏開始編碼實現，編排任務完成應用服務開發。

以上兩個步驟從內至外逐步完成一個完整業務服務的功能開發。

通脈絡

總結以上分析設計步驟，結合軟體開發中心需求項研發體系要求，整理從問題空間到解空間的推導對映關係，形成體系化、標準化的方法論(見圖4)。在某複雜清算業務系統實踐過程中，嚴格執行領域驅動設計統一過程各步驟，保持模型與程式實現同構，分析設計建模的過程同時也是設計開發人員學習業務的過程，為應用積累了寶貴的資產，鍛鍊培養了深刻理解業務的設計開發人員，同時讓程式實現更具業務表達力。

圖4 問題空間到解空間的對映圖

後續工商銀行軟體開發中心將進一步發揮領域驅動設計應對複雜金融業務系統的優勢，堅持以業務模型為中心開展設計開發，並從以下幾方面繼續探索提升：一是將領域驅動設計全過程標準化，完善各個階段的詳細落地指引。二是結合領域驅動設計深化元件化研發，提供完備的工具與框架支撐，降低各個開發團隊學習與應用的門檻。三是不斷探索銀行系統領域建模的最佳實踐，持續最佳化領域建模流程。四是持續根據系統中業務模型的演進對開發組織結構進行微調適配，降低開發團隊之間溝通與協作的成本。