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