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