作者簡介
袁健，中國移動云能力中心SaaS產品部技術專家組成員，曾負責能力開放平臺、云能OA門戶、集中化遠程交付、集中化計劃建設等產品及項目的研發工作，架構設計及研發管理經驗豐富，在微服務架構設計及領域驅動設計方面有較為深入的研究。
導讀
隨著云原生基礎設施的日漸完善，微服務等架構的日漸成熟，信息化系統能夠支撐的業務也越來越復雜。如果沒有適當的方法，就很難對復雜的業務進行分析與實現，云原生基礎設施與架構的效能也很難充分體現。領域驅動設計就是這樣的一種思想，它可以指導研發團隊更好的進行業務分析與規劃，高效高質的提煉領域模型，用領域模型指導架構設計和研發實現。
一、微服務不是銀彈
1、微服務架構的難點
云原生時代微服務架構由于高擴展性、高容錯性、高可用性以及快捷交付的優勢，得到廣泛的應用。但是微服務架構對研發團隊也存在拆分難、治理難的困擾。微服務拆不好，影響系統的后續擴展與實際運行，微服務的優勢得不到體現。微服務治理不好，影響微服務的運行與后期運維。
2、難點應對措施
目前微服務治理工具發展較為完善，不管從框架層面還是基礎設施層面都有很好的解決方案。相對于微服務治理，微服務拆分沒有實體工具來支撐，更多的是需要設計人員的自身能力，不但需要對業務有很好理解，還需要有一定的技術功底，更需要有科學方法論的加持。但是，往往負責微服務拆分的設計人員都缺少科學方法論的支撐，領域驅動設計思想正好能彌補這一方面的空缺。
二、完善的設計思想-領域驅動設計
1、什么是領域驅動設計
領域驅動設計不是架構方法，也不是設計模式，就是一種思維方式（在此基礎上延伸出了一些方法論），通過領域驅動設計這種思維方式，定義領域模型，從而確定業務邊界和應用邊界，保證業務模型和代碼模型的一致性。
很多讀者因為其復雜的理論而認為領域驅動設計只適用于復雜系統或者是微服務架構的系統。這是認識上的誤區，由于整套理論的目的之一是解決設計與研發脫節的問題，因此對于簡單業務或者單體系統也同樣適用。
2、領域驅動思想的由來與發展
領域驅動設計思想首先是Eric Evans提出來的，后來又由Jimmy Nilsson等人不斷的充實和豐富。當前這個思想不是一蹴而就的，在他之前Martin Fower先提出了技術架構領域的設計模式思想。
• 2002年Martin Fower在其出版《企業應用架構模式》中，歸納總結了40多種企業應用架構的設計模式。其中所提到的多種設計模式和概念，如事務腳本、活動記錄和領域模型等，對業界產生了深遠的影響。
• 2004年著名建模專家Eric Evans發表了他最具影響力的著名書籍：《Domain-Driven Design –Tackling Complexity in the Heart of Software》（中文譯名：領域驅動設計—軟件核心復雜性應對之道），書中提出了“領域驅動設計(簡稱DDD)”的概念。
• 此后Jimmy Nilsson的《Applying Domain-Driven Design and Patterns》、Abel Avram和Floyd Marinescu合作的《Domain-Driven Design Quickly》、Dan Haywood的《Domain-Driven Design Using Naked Objects》、以及Vaughn Vernon的《Implementing Domain-Driven Design》等書籍的出版，豐富了領域驅動設計的實踐和指導。
領域驅動設計思想基于架構設計模式，相輔相成，互為補充。Martin Fower的架構設計模式主要是技術架構的設計方法論。而Eric Evans的領域驅動設計填補了業務領域設計的空白，并且為業務設計到技術設計的銜接起到了重要的指導作用，Eric Evans提出領域驅動思想的一個重要目的之一就是希望業務架構設計人員不能和一線研發人員脫節，要不斷接收研發的反饋，不斷的迭代業務架構的設計，使設計真正的能夠落地。
3、領域驅動設計的過程
領域驅動設計貫穿了整個軟件開發的生命周期，包括對需求的分析，建模，架構，設計以及最終的編碼實現。大致可以分為兩個階段，戰略設計和戰術設計。所謂戰略設計，可以簡單理解為粗粒度設計，即領域的劃分。所謂戰術設計，可以簡單理解為細粒度的設計，采用模型驅動設計方法對各領域分而治之，不涉及技術層面的細節但對研發具有指導意義。
領域驅動設計過程是一個演進的過程，戰略設計控制和分解戰術設計的邊界與粒度，戰術設計則以實證角度驗證領域模型的有效性、完整性與一致性，進而以演進的方式對之前的戰略設計階段進行迭代，從而形成一種螺旋式上升的迭代設計過程，兩個不同階段的設計目標是保持一致的，它們是一個連貫的過程，彼此之間又相互指導與規范，并最終保證一個有效的領域模型和一個富有表達力的實現同時演進，如下圖所示：
三、領域驅動設計思想的微服務實踐案例
1、實踐案例介紹
1.1、實踐案例背景及目標
隨著中國移動戰略轉型，計劃建設領域的項目管理辦法逐漸完善及各省信息化系統的逐步實施，導致當前計劃建設管理系統為集團與省公司兩級平臺的建設方式，存在管理方式不統一，精細化管理水平差異大，數據標準化和互通流轉不暢,嵌入式風險管理薄弱等問題，已不能滿足日益提高的項目管理要求，亟待建設集中化的計劃建設管理系統，以達到規范各省項目管理流程、統一數據規范、防范生產及管理風險等目的。
基于上述背景，中國移動集團啟動了集中化計劃建設系統的研發工作。集中化計劃建設管理系統是一個融管理, 業務, 架構于一體的管理系統，實現了計劃建設領域全生命周期流程覆蓋、全專業支撐，要求做到管理一體化、業務一體化以及架構一體化。
1.2、項目研發存在諸多困難與挑戰
集中化計劃建設系統由于需要在管理、業務以及架構三個維度對全國各省各專業公司已有系統及數據進行統一管理，因此在這三個維度分別存在巨大的困難與挑戰。
• 業務維度：隨著業務持續演進，業務復雜度越來越高，業務要求的響應速度也越來越快。
• 技術維度：流程數量較多，流程設計、變更頻次高，對平臺易用性及擴展性要求越來越高；接口交互調用頻次高，對性能及穩定性要求較高；分布式部署環境復雜，需要同時支持集中監控及分域管理。
• 管理維度：跨系統間協作，參與單位多，涉及的人員多，管理復雜度高；流程數量較多，流程發布、變更、下線等管理復雜度高。
針對以上三個維度的困難，在架構及業務領域設計上分別采用了先進的微服務+PaaS的架構模式和領域驅動設計思想。
1.3、采用微服務+PaaS技術架構
系統包括多個獨立自治的子模塊、對于系統可擴展性、容錯率等要求較高，這些要求與微服務架構的優點不謀而合；同時由于其對接系統多、體量大、資源維護難度大，若采用傳統管理模式勢必帶來資源難以管控等問題，因此采用PaaS平臺化的管理模式進行資源及能力統一管控，有利于實現系統彈性擴展能力。
1.4、采用領域驅動設計解決業務復雜問題
由于計劃建設管理系統目標是建設全國集中的、服務一線生產與管理的系統，并且能夠達到規范各單位項目管理流程、統一數據規范、防范生產及管理風險等目的，實現計劃建設領域全生命周期流程覆蓋，全專業支撐，內部及外部用戶全員使用，因此業務邏輯非常復雜。
系統整體業務復雜，從投資計劃到項目歸檔貫穿資產管理全生命周期，沒有科學的業務分析方法，很難做到業務的細化拆解，實現高內聚低耦合的目標，項目團隊通過深入調研和對比，最終決定采用領域驅動設計思想解決目前面臨的業務復雜、微服務拆解困難的問題。
2、基于領域驅動設計思路的微服務落地
項目整體采用領域驅動設計思想。領域驅動設計是自頂向下的設計方法，先在業務期望明確的基礎上進行戰略設計，再進行戰術設計。戰略設計從宏觀角度來觀察和審視軟件系統，戰術設計將戰略設計進行具體化和細節化，側重于技術實現。統一語言的建立貫穿整個項目研發的始終。
2.1、項目團隊領域驅動設計實踐概覽及團隊協作關系
項目團隊在領域專家的帶領下通過對行業最佳實踐的學習以及對PMS現狀診斷及業務期望的分析，梳理系統全景業務流程并對流程進行業務邊界的劃分。基于業務邊界，依據康威定律劃分團隊，各團隊由領域專家和研發組成，每個團隊在各自的業務領域進行分析與設計，團隊間協作關系由項目經理進行協調。架構師在領域專家配合下，在技術實現層面進行微服務設計指導研發編碼實現。
2.2、系統的頂層價值設計
2.2.1、業務期望分析與明確
分析系統的業務期望，首先需要分析系統的相關干系人，對干系人進行歸納，分析他們對系統的期望。借助業務需求和管理關注點分析模型，發現并匯總集團、省分、地市不同關注者的關注點和問題，明確各環 節投資與建設目標。
組織干系人進行頭腦風暴，以便干系人對業務系統期望達成一致。在設計過程中，團隊成員對于愿景的輸入相對較少，潛在原因是前期未達成共識，討論思想較少，目標系統 知識缺乏，主要通過目標系統歸口部門完成相關的信息輸入。
2.2.2、統一語言的建立
為了統一所有領域公共概念的表達形式，項目組在開始進行領域分析之前，先把全局概念進行定義，為戰略設計階段的分析奠定溝通基礎。所有領域專家與研發團隊分別從計劃建設主流程的資金管理和項目管理兩條線進行梳理，從全局角度提煉統一語言。首先梳理了67條核心業務概念，待后續領域劃分好之后，各個領域團隊再逐步細化與定義各自的領域術語，進行領域內表達方式的統一。
2.3、戰略設計階段
2.3.1、業務全景分析
進入戰略設計階段，基于事件風暴分析方法，以領域專家為主導，大家從項目前期、項目實施以及項目收尾三個階段，梳理了從需求規劃到項目結束，包含72個核心事件的全景業務流程。為進一步領域劃分展示了清晰的全景視圖。
事件風暴是一種高度強調交流與協作的可視化工作坊，在分析過程匯總，重點尋找業務流程中產生的領域事件，探索出業務全景。基于業務全景以及事件表達的業務概念，就可以對領域進行劃分，確定子領域和限界上下文。
2.3.2、領域分析與微服務劃分
基于業務全景圖，領域專家和研發團隊對系統業務場景分三個階段（項目前期、項目實施以及項目收尾）進行領域分析與劃分。通過識別限界上下文，聚焦核心領域，以項目前期階段3個核心領域，項目實施階段3個核心領域以及項目收尾階段4個核心領域為中心進行分析，劃分出15個業務域，并通過上下文映射建立它們之間的關系。最后，基于核心業務領域的劃分，領域專家與技術專家進一步分析支撐核心領域的技術能力及非核心領域功能，在核心領域基礎上擴展出20個領域，最終基于領域劃分20個微服務。同時領域專家和研發團隊按微服務分成20個研發小組，一個微服務團隊領域專家和技術專家各一名。
2.4、戰術設計階段
在完成微服務劃分之后，項目組進入單個微服務的詳細設計階段。20個微服務按組分別進行領域模型分析，整個分析過程借鑒了事件風暴和領域模型驅動設計的方法，先對領域進行事件分析，然后細分領域，進行領域內模塊的劃分，最后對領域模型進行建模，指導研發工程師進行程序的研發。期間隨著領域模型分析的不斷深入，各微服務的模型也不斷進行迭代與重構。
其中以物資微服務為例，通過分析劃分出8個模塊（基礎數據、項目領料、物資接收、物料平衡、現場物資、現場物資調撥、項目退料和庫存查詢），然后分別對每個模塊進行建模，指導研發工程師建立ER關系圖。
整個建模過程圍繞業務需求，分析與提煉領業務需求中的領域知識。為了避免受技術的干擾，完全表達業務的邏輯關系，建模過程由領域專家主導，在領域專家指導審核下，模型由研發團隊創建，保證模型的順利落地，業務與技術不脫節。
總結
領域驅動設計的核心是化繁為簡，思想上有其普適性，方法上有其特殊性。實現上大概可以概括為，先以分層架構突出業務領域，再以模型驅動的方法把業務進行領域劃分，最后細分模型指導架構設計與研發實現。在實際研發過程中應該合理采用領域驅動設計思想，揚長避短，靈活運用。
隨著信息化程度的日益增高，業務和技術已深度融合。在業務對技術的要求不斷提高的同時，技術對業務的要求也在不斷提升。沒有好的業務架構設計，要設計好技術架構就會很存在很大的局限性。在業務分析階段應優先考慮領域問題，只有在業務分析透徹的基礎上，才能設計出高內聚低耦合、擴展性良好的技術架構。
