一、架構(gòu)設(shè)計(jì)理念與技術(shù)

1.架構(gòu)演變路徑

圖片

• 單體（又稱巨石系統(tǒng)）：所有業(yè)務(wù)融合于一體。在項(xiàng)目早期，公司一般會(huì)選擇單體以降低運(yùn)營(yíng)等各方面成本。
• 服務(wù)化：隨著業(yè)務(wù)飛速發(fā)展和流量增長(zhǎng)，進(jìn)入了服務(wù)化階段。在此階段，經(jīng)歷服務(wù)拆分、治理和模型抽象。
• 平臺(tái)化：業(yè)務(wù)膨脹期過(guò)后，服務(wù)化維護(hù)成本高，服務(wù)粒度拆分過(guò)細(xì)、重復(fù)造輪子、系統(tǒng)交互混亂等問(wèn)題暴露，因此邁向平臺(tái)化（服務(wù)能力沉淀、服務(wù)合并、領(lǐng)域自治等）。
• 中臺(tái)化：打造企業(yè)級(jí)能力復(fù)用平臺(tái)，是平臺(tái)化的下一站，其具備數(shù)據(jù)互通能力和業(yè)務(wù)變化高響應(yīng)力。

業(yè)務(wù)架構(gòu)的演變路徑，側(cè)面展現(xiàn)所在互聯(lián)網(wǎng)企業(yè)的演變路徑。每一種架構(gòu)無(wú)關(guān)好壞，選擇與否，只取決于是否適合當(dāng)下及可預(yù)見(jiàn)的未來(lái)。

本次分享主要介紹從服務(wù)化到平臺(tái)化的過(guò)程，即從服務(wù)細(xì)粒度到領(lǐng)域能力沉淀的演進(jìn)過(guò)程。

2.架構(gòu)設(shè)計(jì)理念

圖片

從業(yè)務(wù)出發(fā)、面向業(yè)務(wù)變化是架構(gòu)設(shè)計(jì)成功的關(guān)鍵，指導(dǎo)業(yè)務(wù)架構(gòu)設(shè)計(jì)的維度包括：

1）商業(yè)模式及成熟度

傳統(tǒng)行業(yè)的業(yè)務(wù)相對(duì)穩(wěn)定和成熟，非必要情況下建議做成單一服務(wù)。如需拆分，建議將變化頻繁與不頻繁的業(yè)務(wù)拆分。

互聯(lián)網(wǎng)行業(yè)則分為初創(chuàng)公司與成熟穩(wěn)定的公司：

• 初創(chuàng)、商業(yè)不穩(wěn)定的公司：需要多種業(yè)務(wù)進(jìn)行快速試錯(cuò)，可使用微服務(wù)。以微小的單體制服務(wù)器，快速構(gòu)造探索場(chǎng)景，以技術(shù)的確定性來(lái)應(yīng)對(duì)未來(lái)發(fā)展的不確定性。去哪兒網(wǎng)的某些團(tuán)隊(duì)產(chǎn)生簡(jiǎn)單方案后，可使用微服務(wù)獲取市場(chǎng)反響，快速驗(yàn)證效果。
• 商業(yè)穩(wěn)定或固化的公司：不再需要技術(shù)端的靈活性，也不愿承擔(dān)靈活性帶來(lái)的架構(gòu)維護(hù)成本，此時(shí)可以考慮合并微服務(wù)，以減少運(yùn)營(yíng)成本。

目前旅游行業(yè)已相對(duì)穩(wěn)定，去哪兒網(wǎng)比較符合以上第二種情況，可以考慮將先前拆分粒度太細(xì)的微服務(wù)進(jìn)行合并。這也是去哪兒網(wǎng)的架構(gòu)演進(jìn)原因之一，原有業(yè)務(wù)拆分太細(xì)，達(dá)到人均10個(gè)應(yīng)用，維護(hù)成本極高。

2）面向業(yè)務(wù)的變化

• 組件設(shè)計(jì)圍繞業(yè)務(wù)變化
• 組件調(diào)用非強(qiáng)依賴
• 組件業(yè)務(wù)復(fù)用
• 組件顆粒度與成熟度

為快速適應(yīng)業(yè)務(wù)變化，需識(shí)別業(yè)務(wù)核心問(wèn)題，劃清業(yè)務(wù)邊界，達(dá)到業(yè)務(wù)組件的復(fù)用最大化；區(qū)別出變與不變的業(yè)務(wù)，將變化隔離在一定范圍內(nèi)，進(jìn)而減少變化。

面向業(yè)務(wù)變化與不變的情況下，組件顆粒度要拆分到什么程度？

組件拆分粒度過(guò)細(xì)時(shí)，可復(fù)用性強(qiáng)，但組裝麻煩；拆分粒度過(guò)大時(shí)，好用，但使用場(chǎng)景比較少。

3）技術(shù)延遲決策

《架構(gòu)整潔之道》一書講到：“良好的架構(gòu)設(shè)計(jì)應(yīng)該只關(guān)注用例，并能將他們與其他的周邊因素隔離?！鼻捌趹?yīng)該只關(guān)注用例，在后期決策使用的具體技術(shù)。

圖片

4）康威和逆康威定律

• 康威定律：產(chǎn)品必然是其組織溝通結(jié)構(gòu)的縮影。系統(tǒng)設(shè)計(jì)本質(zhì)上反映了企業(yè)的組織架構(gòu)，系統(tǒng)各模塊之間的接口，反映了企業(yè)各部門之間信息流動(dòng)和合作的方式。
• 逆康威定律：當(dāng)前組織效率不夠高時(shí)，可優(yōu)先進(jìn)行系統(tǒng)設(shè)計(jì)，通過(guò)系統(tǒng)設(shè)計(jì)來(lái)演進(jìn)后續(xù)的組織架構(gòu)。去哪兒網(wǎng)在2021年實(shí)行對(duì)內(nèi)DDD對(duì)外API的戰(zhàn)略，對(duì)團(tuán)隊(duì)和職責(zé)進(jìn)行合理劃分，這是逆康威定律的實(shí)例之一。

5）面向測(cè)試、運(yùn)維

測(cè)試是保證系統(tǒng)質(zhì)量的重要途徑，使用TDD驗(yàn)證架構(gòu)是否合理、是否可以隔離、測(cè)試性好不好。

6）軟件質(zhì)量屬性

在運(yùn)行期和開(kāi)發(fā)期，軟件質(zhì)量屬性體現(xiàn)為可用性、可修改性、性能、安全性、易用性等。以功能性為主進(jìn)行架構(gòu)設(shè)計(jì)，以質(zhì)量屬性為依據(jù)進(jìn)行增量式迭代重構(gòu)和優(yōu)化。

圖片

上圖是架構(gòu)的一些關(guān)鍵技術(shù)，這張圖的粒度較粗。從下往上看，公司底層基本都由容器與自動(dòng)化支撐，上層是監(jiān)控和治理、前后端分離的系統(tǒng)?；诖藞D，DDD是整個(gè)架構(gòu)的指導(dǎo)思想。

二、業(yè)務(wù)系統(tǒng)重構(gòu)背景

1.業(yè)務(wù)介紹：酒店基礎(chǔ)信息

圖片

上列四張圖簡(jiǎn)單展示了去哪兒網(wǎng)本次重構(gòu)的主題，也是酒店基礎(chǔ)信息部所負(fù)責(zé)的業(yè)務(wù)。

• 列表頁(yè)：用戶打開(kāi)APP，填寫地址與入住時(shí)間，點(diǎn)擊搜索，就會(huì)跳轉(zhuǎn)到列表頁(yè)，可以看到搜索地點(diǎn)的所有酒店列表信息。
• 詳情頁(yè)：點(diǎn)擊希望入住的酒店，即可進(jìn)入詳情頁(yè)。
• 酒店Info：點(diǎn)擊酒店名字，則可進(jìn)入酒店Info頁(yè)。
• 進(jìn)訂頁(yè)：用戶決定預(yù)定酒店房間后，就跳轉(zhuǎn)到進(jìn)訂頁(yè)。

2.基礎(chǔ)信息業(yè)務(wù)架構(gòu)

圖片

上圖是酒店基礎(chǔ)信息業(yè)務(wù)對(duì)應(yīng)的架構(gòu)。去哪兒網(wǎng)售賣的酒店，來(lái)源于各個(gè)代理商和集團(tuán)分銷的信息，按照?qǐng)D示自下到上，經(jīng)過(guò)基礎(chǔ)層，然后到達(dá)基礎(chǔ)信息部門的主要業(yè)務(wù)層。

業(yè)務(wù)層最重要的內(nèi)容是酒店聚合，包括代理商酒店Tree和Q物理酒店。我們將各個(gè)代理商提供的酒店信息，按照一定業(yè)務(wù)邏輯規(guī)則，聚合到去哪兒網(wǎng)的Q側(cè)物理酒店，將此部分信息對(duì)外售賣，從而提升用戶體驗(yàn)。

為什么能夠提升用戶體驗(yàn)？

舉個(gè)例子，比如現(xiàn)在投放的是季楓酒店，A代理商將其稱為季楓酒店北京店，B代理商將其稱為季楓酒店北京中關(guān)村店，C代理商稱之為季楓酒店北京中關(guān)村蘇州街店，用戶容易混淆。所以去哪兒網(wǎng)將各個(gè)代理商提供的酒店信息，按照一定的業(yè)務(wù)邏輯、規(guī)則聚合為外網(wǎng)能夠看到的、唯一的物理酒店。

酒店Tree的含義是，每個(gè)代理商投放的酒店，映射到去哪兒網(wǎng)的酒店，以去哪兒網(wǎng)的酒店為樹(shù)根，下方掛靠不同代理商投放的酒店信息，形成對(duì)應(yīng)關(guān)系。

當(dāng)前我們團(tuán)隊(duì)的核心業(yè)務(wù)是，將基于業(yè)務(wù)層的酒店信息，提供給應(yīng)用層，比如提供APP搜索或篩選下展示的信息。

3.落地技術(shù)中心戰(zhàn)略，償還技術(shù)債務(wù)

圖片

旅游行業(yè)應(yīng)該是受疫情影響最大的行業(yè)之一，在此背景下，技術(shù)中心在2022年提出“鞏固效率之本，分擔(dān)產(chǎn)品之憂”的戰(zhàn)略，自此開(kāi)啟DDD重構(gòu)之路。

如上圖，重構(gòu)前，業(yè)務(wù)和業(yè)務(wù)架構(gòu)存在以下問(wèn)題：

• 核心業(yè)務(wù)分散：上圖的灰色條塊是我們的核心業(yè)務(wù)，被耦合于整條鏈路，分散在各個(gè)系統(tǒng)中，導(dǎo)致核心業(yè)務(wù)入侵。
• 核心業(yè)務(wù)入侵：產(chǎn)品需求交付效率低下，一個(gè)產(chǎn)品需求可能需要調(diào)整5個(gè)微服務(wù)。
• 數(shù)據(jù)寫入鏈路長(zhǎng)：沒(méi)有對(duì)核心業(yè)務(wù)的收口能力，數(shù)據(jù)更新不及時(shí)。由于沒(méi)有實(shí)時(shí)查詢能力，別的團(tuán)隊(duì)調(diào)用數(shù)據(jù)時(shí)，需拉取并自行緩存。

4.系統(tǒng)重構(gòu)模式選擇

沒(méi)有最好的架構(gòu)，只有最合適的架構(gòu)。以下是備選的系統(tǒng)重構(gòu)模式：

圖片

• 修繕者：在現(xiàn)有系統(tǒng)的基礎(chǔ)上，新增一個(gè)抽象層，保證對(duì)外提供能力不變，然后對(duì)系統(tǒng)內(nèi)部進(jìn)行改造。
• 絞殺者：修繕沒(méi)有辦法適應(yīng)現(xiàn)狀的情況下，需要另起爐灶，在系統(tǒng)以外重新構(gòu)建新功能，逐步剝離原有邏輯。對(duì)外提供新功能，逐步絞殺各個(gè)需要下線或重構(gòu)的服務(wù)。重構(gòu)時(shí)需要權(quán)衡絞殺者的優(yōu)缺點(diǎn)。
• 優(yōu)點(diǎn)：不影響原有業(yè)務(wù)，一旦條件成熟，新系統(tǒng)可以完全替換舊系統(tǒng)。
• 缺點(diǎn)：一段時(shí)間內(nèi)需要維護(hù)兩套系統(tǒng)，付出額外的開(kāi)發(fā)維護(hù)成本。
• 演進(jìn)式：老項(xiàng)目的邏輯已經(jīng)模糊，需要進(jìn)行演進(jìn)式迭代。識(shí)別老系統(tǒng)中的核心業(yè)務(wù)邏輯，從MVP版本開(kāi)始小步快跑，先迭代核心業(yè)務(wù)，快速上線查看效果，然后將剩下的邊緣業(yè)務(wù)逐漸切換過(guò)來(lái)，及時(shí)調(diào)整。
• 優(yōu)點(diǎn)：有效控制迭代風(fēng)險(xiǎn)，避免全部替換系統(tǒng)，造成難以估量的影響。

三、系統(tǒng)重構(gòu)改造模式與架構(gòu)選擇

前文講解了架構(gòu)的演變路徑、理念及改造模式的選擇，最終衍生出來(lái)的系統(tǒng)重構(gòu)框架是什么樣子？

1.系統(tǒng)重構(gòu)模式選擇

圖片

從業(yè)務(wù)出發(fā)、面向業(yè)務(wù)變化是我們現(xiàn)代架構(gòu)設(shè)計(jì)成功的關(guān)鍵，DDD的設(shè)計(jì)思想完全符合成功架構(gòu)設(shè)計(jì)的理念。

1）服務(wù)業(yè)務(wù)戰(zhàn)略

站在EA（企業(yè)架構(gòu)）角度（包括業(yè)務(wù)架構(gòu)BA、應(yīng)用架構(gòu)AA、數(shù)據(jù)架構(gòu)DA、技術(shù)架構(gòu)TA），DDD可以綁定業(yè)務(wù)架構(gòu)和應(yīng)用架構(gòu)，將問(wèn)題域與應(yīng)用架構(gòu)相剝離；通過(guò)DDD將業(yè)務(wù)架構(gòu)的“價(jià)值流+業(yè)務(wù)能力”進(jìn)行解構(gòu)化分解，能力下沉。同時(shí)依據(jù)DDD劃分的限界上下文、聚合，進(jìn)行應(yīng)用架構(gòu)的搭建，實(shí)現(xiàn)自下而上的“高內(nèi)聚、低耦合”的應(yīng)用。

2）演進(jìn)式架構(gòu)

DDD的核心思想有哪些：

• 戰(zhàn)略層面：業(yè)務(wù)問(wèn)題分析→分解子問(wèn)題域，識(shí)別核心域→分而治之，降低業(yè)務(wù)復(fù)雜度；
• 戰(zhàn)術(shù)層面：識(shí)別問(wèn)題域的不同業(yè)務(wù)上下文→領(lǐng)域建模，定義聚合，組件化業(yè)務(wù)需求→指導(dǎo)微服務(wù)的拆分；
• 實(shí)現(xiàn)層面：利用成熟的分層模式、依賴倒置屏蔽掉技術(shù)細(xì)節(jié)復(fù)雜度，通過(guò)DDD方法設(shè)計(jì)的微服務(wù)，不僅可以通過(guò)限界上下文和聚合實(shí)現(xiàn)微服務(wù)內(nèi)外的解耦，同時(shí)也可以很容易地實(shí)現(xiàn)業(yè)務(wù)功能積木式模塊的重組和更新，從而實(shí)現(xiàn)架構(gòu)演進(jìn)。

總之，自上而下地拆解業(yè)務(wù)，并以此為指導(dǎo)，自下而上地構(gòu)建模型，最終達(dá)到高內(nèi)聚低耦合的狀態(tài)。

我們選擇絞殺模式和演進(jìn)模式，進(jìn)行系統(tǒng)重構(gòu)。由于系統(tǒng)復(fù)雜程度高、了解業(yè)務(wù)細(xì)節(jié)的同學(xué)少，為了減少重構(gòu)對(duì)現(xiàn)有業(yè)務(wù)的影響，我們將核心資源投入到核心業(yè)務(wù)中，快速上線以便查看效果，下文將具體介紹演進(jìn)實(shí)踐。

四、以業(yè)務(wù)驅(qū)動(dòng)的微服務(wù)架構(gòu)演進(jìn)實(shí)踐

1. 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)過(guò)程

圖片

上圖是以業(yè)務(wù)驅(qū)動(dòng)的微服務(wù)架構(gòu)演進(jìn)的實(shí)戰(zhàn)過(guò)程，介紹DDD的完整流程和關(guān)鍵路徑。進(jìn)行領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)時(shí)，需要對(duì)組內(nèi)成員進(jìn)行定位。最重要的是識(shí)別領(lǐng)域?qū)＜遥茨男┤藢?duì)該領(lǐng)域認(rèn)知深刻，能夠幫助成員深入理解業(yè)務(wù)，有利于后續(xù)腦暴和建模過(guò)程順利進(jìn)行；其次是識(shí)別技術(shù)專家和開(kāi)發(fā)團(tuán)隊(duì)。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的關(guān)鍵路徑如下：

第一步，領(lǐng)域?qū)＜液烷_(kāi)發(fā)團(tuán)隊(duì)就具體問(wèn)題，明確業(yè)務(wù)愿景，討論需求，從而建立統(tǒng)一語(yǔ)言，形成領(lǐng)域知識(shí)。統(tǒng)一語(yǔ)言，即對(duì)問(wèn)題域內(nèi)的概念統(tǒng)一認(rèn)知，比如大家明確某個(gè)詞語(yǔ)的定義且沒(méi)有歧義，大大降低交流成本。

第二步，分析問(wèn)題域并劃分子域（比如核心子域、支撐子域、通用子域），進(jìn)而劃分限界上下文，構(gòu)建上下文地圖。

第三步，領(lǐng)域建模并實(shí)現(xiàn)模型。將以上兩步分析，投射到代碼層面進(jìn)行模型實(shí)現(xiàn)，這一步驟可總結(jié)為“兩關(guān)聯(lián)一循環(huán)”?！皟申P(guān)聯(lián)”是指，統(tǒng)一語(yǔ)言和模型相關(guān)聯(lián)、模型與軟件實(shí)踐相關(guān)聯(lián)?！耙谎h(huán)”是指，實(shí)踐過(guò)程可能經(jīng)歷種種困難與不確定性，需要在不斷循環(huán)的過(guò)程中提煉知識(shí)，最終得到趨向完美的模型。

2.基于DDD落地實(shí)踐

圖片

上圖展示了基于DDD落地實(shí)踐的過(guò)程。首先是定位愿景，其重要性在于決定了后續(xù)的發(fā)展道路；其次，分析問(wèn)題域中現(xiàn)有業(yè)務(wù)場(chǎng)景；然后基于劃分的子域，識(shí)別限界上下文；最后在限界內(nèi)進(jìn)行領(lǐng)域建模、實(shí)現(xiàn)模型。

1）問(wèn)題域分析

① 定位愿景

圖片

麥肯錫提出“電梯演講”概念是指，在乘坐電梯的30秒之內(nèi)，向顧客清晰準(zhǔn)確地解釋解決方案，即使用簡(jiǎn)短的語(yǔ)言精準(zhǔn)說(shuō)明業(yè)務(wù)價(jià)值。比如，去哪兒網(wǎng)的核心價(jià)值是“總有你要的低價(jià)”。因此，所有的核心工作都要圍繞低價(jià)展開(kāi)，落實(shí)到基礎(chǔ)信息團(tuán)隊(duì)，我們的愿景就是提供多樣的信息聚合。

② 明確領(lǐng)域?qū)＜?/h5>

由于產(chǎn)品迭代頻繁，系統(tǒng)演進(jìn)缺少領(lǐng)域?qū)＜?，所以按照產(chǎn)品、QA、技術(shù)人員的順位確定領(lǐng)域?qū)＜摇?/p>

圖片

為剖析原有項(xiàng)目中，哪些用戶用例與愿景強(qiáng)相關(guān)，我們整理用例圖并安排同學(xué)逐一分析。由此發(fā)現(xiàn)，經(jīng)過(guò)多年迭代，很多業(yè)務(wù)已經(jīng)不再使用，舊業(yè)務(wù)無(wú)法適應(yīng)現(xiàn)有商業(yè)模式。所以我們將此類業(yè)務(wù)下線，或轉(zhuǎn)投資源，最終將188個(gè)用例減少為79個(gè)用例，極大簡(jiǎn)化工作內(nèi)容。

圖片

③ 事件風(fēng)暴

事件風(fēng)暴主要關(guān)注三件事：識(shí)別領(lǐng)域事件、識(shí)別決策命令、識(shí)別領(lǐng)域名詞。

事件風(fēng)暴的輸出，將作為后續(xù)領(lǐng)域建模的輸入，需要遵循以下原則：

• 業(yè)務(wù)視角事件：從業(yè)務(wù)視角分析領(lǐng)域事件，比如，某個(gè)業(yè)務(wù)動(dòng)作對(duì)內(nèi)產(chǎn)生某種數(shù)據(jù)，觸發(fā)業(yè)務(wù)流程狀態(tài)變化，對(duì)外發(fā)送消息。技術(shù)人員進(jìn)行頭腦風(fēng)暴時(shí)，很容易陷入代碼細(xì)節(jié)，忘記最初目的。
• 先發(fā)散，再收斂：先將所有想法羅列出來(lái)，在此基礎(chǔ)上再進(jìn)行收斂。
• 決策命令：哪些人做了哪些動(dòng)作導(dǎo)致了事件產(chǎn)生。

④ 統(tǒng)一語(yǔ)言

圖片

沒(méi)有DDD經(jīng)驗(yàn)的同學(xué)可能會(huì)問(wèn)，什么可以作為統(tǒng)一語(yǔ)言？

答案是，什么都可以作為團(tuán)隊(duì)的統(tǒng)一語(yǔ)言。比如，一個(gè)老系統(tǒng)的內(nèi)部邏輯特別復(fù)雜難懂，這部分代碼的重構(gòu)代價(jià)大，難以改動(dòng)，就可以作為團(tuán)隊(duì)內(nèi)部的統(tǒng)一語(yǔ)言。由此，產(chǎn)品和技術(shù)同學(xué)都知道老系統(tǒng)的目標(biāo)、能力及應(yīng)對(duì)態(tài)度。

技術(shù)同學(xué)表達(dá)事情的思維，偏向代碼邏輯，導(dǎo)致和產(chǎn)品同學(xué)溝通存在偏差。此時(shí)，統(tǒng)一語(yǔ)言可以拉齊雙方認(rèn)知，技術(shù)同學(xué)只要拋出幾個(gè)領(lǐng)域名詞，產(chǎn)品同學(xué)即可理解。

需要注意的是，統(tǒng)一語(yǔ)言的術(shù)語(yǔ)表應(yīng)具備中英文對(duì)照，便于后期編解碼時(shí)，在代碼層面達(dá)成認(rèn)知統(tǒng)一。

2）識(shí)別限界及子域劃分

圖片

識(shí)別限界上下文的總體原則是先業(yè)務(wù)后技術(shù)，上圖展示了領(lǐng)域?qū)用娴膭澐至鞒獭?/p>

• 降低業(yè)務(wù)復(fù)雜度：業(yè)務(wù)層面，需要杜絕語(yǔ)言的二義性。比如，在去哪兒網(wǎng)內(nèi)部，商務(wù)同學(xué)、技術(shù)同學(xué)可能對(duì)“酒店”一詞的認(rèn)知不同，限界上下文時(shí)就要避免這種情況。
• 降低管理復(fù)雜度：基于領(lǐng)域?qū)觿澐值臉I(yè)務(wù)邊界，影響工作邊界的劃分。上文提到的康威定律以及著名的兩個(gè)披薩原則（一個(gè)高效的技術(shù)研發(fā)團(tuán)隊(duì),最佳的團(tuán)隊(duì)規(guī)模應(yīng)該控制在2個(gè)披薩就可以吃飽的人數(shù)），都對(duì)工作邊界具有指導(dǎo)意義。
• 降低技術(shù)復(fù)雜度：限界上下文承接的流量不同，我們通過(guò)制作彈性邊界、部署及可用性測(cè)試，使用不同方式對(duì)待不同的限界上下文。

圖片

限界上下文的特征：

• 最小完備原則：自治單位履行的職責(zé)是完整的，無(wú)需求助其他自治單位獲取自己的信息。
• 自我履約原則：自治單元自身決定職責(zé)。比如，進(jìn)行代理商酒店的抓取落地時(shí)，無(wú)需進(jìn)行后續(xù)解析。
• 穩(wěn)定空間原則：外部變化不會(huì)影響自治單元。
• 獨(dú)立進(jìn)化原則：對(duì)外提供穩(wěn)定接口，內(nèi)部變化不影響外部。

繪制上下文依賴地圖時(shí)，謹(jǐn)記三不原則：不要雙向依賴、不要循環(huán)依賴、不要過(guò)長(zhǎng)依賴。

如上右圖所示，我們?cè)谥谱魃舷挛囊蕾嚨貓D時(shí)發(fā)現(xiàn)，酒店解析依賴酒店抓取，酒店抓取依賴酒店聚合信息，酒店聚合信息依賴靜態(tài)信息，靜態(tài)信息依賴酒店解析出來(lái)的數(shù)據(jù)，形成循環(huán)，所以劃分方式不合適?；谶@種情況，創(chuàng)造出“酒店上下文”環(huán)節(jié)，打破循環(huán)依賴。

圖片

在限界上下文后，需要識(shí)別核心域、支撐域和通用域，劃分參考是與業(yè)務(wù)愿景的相關(guān)性。識(shí)別子域的好處是，對(duì)外可以明確告知自身核心競(jìng)爭(zhēng)力；對(duì)內(nèi)明晰人員的資源分配、機(jī)器資源分配，評(píng)估產(chǎn)品需求的優(yōu)先級(jí)、是否位于核心領(lǐng)域內(nèi)。

3）領(lǐng)域建模

圖片

依據(jù)事件風(fēng)暴和限界上下文的輸出，可以構(gòu)建領(lǐng)域模型。

① 建模意義

• 聚合來(lái)表達(dá)業(yè)務(wù)“高內(nèi)聚，低耦合”
• 降低業(yè)務(wù)復(fù)雜度，更好地適應(yīng)業(yè)務(wù)變化

② 建模過(guò)程

• 識(shí)別實(shí)體、值對(duì)象、豐富領(lǐng)域邏輯
• 定義聚合、識(shí)別聚合根

建模過(guò)程中最難把握的是尺度，哪些方法應(yīng)該加入模型，屬性應(yīng)該放在哪個(gè)模型。個(gè)人建議是共識(shí)即正確，無(wú)論是否正確，組內(nèi)達(dá)成共識(shí)，這個(gè)決策在當(dāng)下就是正確的。因?yàn)榻Ｊ茄h(huán)提煉的過(guò)程，隨著后續(xù)深化業(yè)務(wù)理解，推翻之前結(jié)論、一次性創(chuàng)建完美模型的難度較大。

分層架構(gòu)中具有領(lǐng)域?qū)雍蜆I(yè)務(wù)層，如果將功能和用例盲目加入領(lǐng)域?qū)?，領(lǐng)域?qū)优蛎洉?huì)影響復(fù)用性和業(yè)務(wù)表達(dá)力。所以，要承認(rèn)模型和領(lǐng)域能力的不確定性，循序漸進(jìn)地使用迭代方式，將能力下沉到領(lǐng)域模型中。

③ 建模原則

• 重點(diǎn)關(guān)注核心域建模：投入核心資源
• 聚合盡量小，適應(yīng)業(yè)務(wù)變化
• 聚合邊界內(nèi)強(qiáng)一致性
• 抽象模型，防止過(guò)多屬性拍平（DP）：屬性被拍平的弊端是，模型內(nèi)字段太多，無(wú)法識(shí)別識(shí)別模型。

圖片

上圖展示了兩個(gè)原則：共性的業(yè)務(wù)能力優(yōu)先下沉到領(lǐng)域，共性的技術(shù)問(wèn)題抽象成業(yè)務(wù)。

沒(méi)有完美的模型，也沒(méi)有正確的模型，領(lǐng)域模型共識(shí)即正確，所以團(tuán)隊(duì)的綜合能力決定了模型完美程度的上限。提供一個(gè)可參考的檢驗(yàn)技巧，建完模型后，可以用業(yè)務(wù)場(chǎng)景檢驗(yàn)?zāi)Ｐ偷耐暾?。隨之循環(huán)往復(fù)，模型也會(huì)越發(fā)完善。

圖片

④ 落地實(shí)踐時(shí)劃分微服務(wù)

如上所示，業(yè)務(wù)邊界、康威定律、業(yè)務(wù)變更頻率、彈性邊界、技術(shù)選型等，都可作為劃分依據(jù)。

需要注意的是，一個(gè)微服務(wù)可包含多個(gè)限界上下文，但只能包含一種子域類型（核心、通用、支撐），不能將一個(gè)核心域和一個(gè)支撐域放在同一微服務(wù)中。如果支撐域可用性不好，影響核心邏輯，就可能為這個(gè)不太重要的問(wèn)題付出沉重代價(jià)。

4）模型實(shí)現(xiàn)

① 業(yè)務(wù)流程和領(lǐng)域模型映射

圖片

如上所示，業(yè)務(wù)流程或業(yè)務(wù)用例被分為不同階段，每個(gè)階段又被分為不同活動(dòng)，我們將這些業(yè)務(wù)活動(dòng)與整個(gè)分層架構(gòu)聯(lián)系起來(lái)，構(gòu)建映射關(guān)系。

構(gòu)建映射關(guān)系的好處是，在分層架構(gòu)和領(lǐng)域模型高度內(nèi)聚、完善的情況下，方便后續(xù)需求接入和擴(kuò)展。自上而下分解業(yè)務(wù)流程，分層映射，隔離技術(shù)負(fù)責(zé)度。

② 模型映射代碼清單

圖片

如上圖，應(yīng)用層、領(lǐng)域?qū)?、基礎(chǔ)設(shè)施層是聚合領(lǐng)域?qū)ο?，模型映射代碼清單劃分了每一層具備能力、領(lǐng)域?qū)拥念I(lǐng)域?qū)ο?、是否具有前置依賴?duì)象，包名、類名及方法名，這些內(nèi)容與上文提到的中英文對(duì)照表一一對(duì)應(yīng)。

構(gòu)建這份代碼清單，便于達(dá)成組內(nèi)多人合作，提高開(kāi)發(fā)效率；為新人熟悉項(xiàng)目時(shí)提供參考，快速說(shuō)明項(xiàng)目的核心邏輯與能力。

③ COLA應(yīng)用架構(gòu)

圖片

在代碼開(kāi)發(fā)階段，我們選擇了開(kāi)源框架COLA，其分層架構(gòu)分為適配層、領(lǐng)域?qū)?、?yīng)用層、基礎(chǔ)設(shè)施層。

無(wú)論是COLA還是DDD的分層架構(gòu)，都以業(yè)務(wù)為核心，基于穩(wěn)定的領(lǐng)域模型，對(duì)外提供領(lǐng)域能力。

選擇COLA的原因如下：

• 定義良好的分層結(jié)構(gòu)、規(guī)范；
• 層內(nèi)部結(jié)構(gòu)“聚合分包，功能分類”；
• 提供最佳應(yīng)用架構(gòu)的最佳實(shí)踐：《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》一書只提供思想指導(dǎo)，而COLA給出了可參考的模板。

下圖是我們內(nèi)部基于COLA架構(gòu)落地微服務(wù)的實(shí)踐。

圖片

• Adaptor：多端適配
• Client：業(yè)務(wù)提供的接口，比如Dubbo
• APP：業(yè)務(wù)用例Case的編排，含executor、publish、qschedule等
• Domain（聚合、實(shí)體、值對(duì)象的定義）：
• 業(yè)務(wù)規(guī)則顯示化，包括邏輯判斷，和對(duì)象設(shè)值代表的含義，純內(nèi)存操作
• Entity解決單個(gè)對(duì)象的邏輯變更，領(lǐng)域服務(wù)解決多對(duì)象的業(yè)務(wù)邏輯變更
• 不允許跨聚合調(diào)用
• 充血模型
• Insfrastructure：Repisitory實(shí)現(xiàn)；ACL的定義和實(shí)現(xiàn)
• Common：公共屬性、工具類，由domain調(diào)用  

圖片

上圖是對(duì)前一張圖的具體描述，我們使用的是CQRS模式，即命令查詢職責(zé)分離。

前文的一張圖描述了架構(gòu)重構(gòu)前的狀況：核心業(yè)務(wù)滲透到各個(gè)服務(wù)中，沒(méi)有做收攏聚合，業(yè)務(wù)耦合。而通過(guò)限界劃分、領(lǐng)域建模，即可實(shí)行分離。

基礎(chǔ)設(shè)施層實(shí)現(xiàn)了依賴倒置，即基礎(chǔ)設(shè)施層依賴領(lǐng)域?qū)?，由此無(wú)需關(guān)心領(lǐng)域?qū)邮褂肊S還是Redis進(jìn)行存儲(chǔ)，可專注于領(lǐng)域能力。

重構(gòu)前，沒(méi)有提供實(shí)時(shí)查詢的能力，各個(gè)團(tuán)隊(duì)將數(shù)據(jù)拉走，進(jìn)行本地緩存。重構(gòu)后，基于異步調(diào)用機(jī)制，實(shí)現(xiàn)數(shù)據(jù)持久化，對(duì)外提供查詢。

④ 領(lǐng)域模型與代碼模型映射

圖片

上圖是領(lǐng)域模型與代碼模型的映射。分層對(duì)應(yīng)上一張圖展現(xiàn)的架構(gòu)，在Domain層，按照領(lǐng)域劃分進(jìn)行聚合分包。上圖標(biāo)藍(lán)的Hoteltree就是前文提到的酒店聚合，在這一領(lǐng)域內(nèi)進(jìn)行功能劃分。

圖片

Domain Primitive 是 Value Object 的進(jìn)階版，在原始 VO 的基礎(chǔ)上要求每個(gè)DP擁有概念的整體，而不僅僅是值對(duì)象。在 VO 的 Immutable 基礎(chǔ)上增加了 Validity 和行為。

DP特征：

• 擁有完整的概念整體，精準(zhǔn)定義
• 使用業(yè)務(wù)域中的原生語(yǔ)言
• 業(yè)務(wù)域的最小組成部分，可構(gòu)建復(fù)雜合
• 隱式轉(zhuǎn)顯式

例如，聯(lián)系信息對(duì)外顯示為電話號(hào)碼，背后隱藏了區(qū)號(hào)、國(guó)內(nèi)外來(lái)源等隱式屬性。通過(guò)DP可以找出隱式屬性，并將其轉(zhuǎn)為顯式，這是我們推薦DP的重要原因之一。

五、總結(jié)和思考

1.項(xiàng)目落地效果

1）組織效率

• 組織資源是否集中在了核心業(yè)務(wù)領(lǐng)域；
• 是否能用統(tǒng)一語(yǔ)言溝通描述業(yè)務(wù)，表現(xiàn)在需求評(píng)審、站會(huì)等有關(guān)會(huì)議的效率上；
• 領(lǐng)域知識(shí)是否得到沉淀，是否有人能承擔(dān)“領(lǐng)域?qū)＜摇保?/li>
• 團(tuán)隊(duì)間職責(zé)模糊地帶少，相互扯皮的機(jī)會(huì)少。

2）開(kāi)發(fā)效率

• 模塊粒度是否合適、模塊間依賴是否健康；
• 接口數(shù)量是否穩(wěn)定，不膨脹；
• 因?yàn)楣δ芾斫獠蛔阋鸬腷ug數(shù)量是否低；
• 模塊和接口的自測(cè)性程度高不高；
• 代碼可讀性，人員交接和新人上手是否足夠快。

3）鞏固效率之本，分擔(dān)產(chǎn)品之憂

• 清晰領(lǐng)域，核心子域重點(diǎn)投入；
• 統(tǒng)一語(yǔ)言，減少產(chǎn)運(yùn)研測(cè)溝通成本，增加2名研發(fā)業(yè)務(wù)專家；
• 承接產(chǎn)品需求75%，助力0.5PM；
• 21個(gè)應(yīng)用微服務(wù)，通過(guò)DDD領(lǐng)域劃分后下降到13個(gè)，微服務(wù)減少33%；
• 開(kāi)發(fā)工時(shí)3pd以下產(chǎn)品響應(yīng)效率提升52.3%，3pd以上32.5%，QA工時(shí)下降62.3%；
• 架構(gòu)、聚合分層，功能分類，新人上手快。

2.思維模型改變

圖片

技術(shù)人員從被動(dòng)了解業(yè)務(wù)，到主動(dòng)了解業(yè)務(wù)，解讀業(yè)務(wù)策略變化，為其定義測(cè)量，提議數(shù)字化方案。產(chǎn)品經(jīng)歷的核心價(jià)值是成為技術(shù)與業(yè)務(wù)連接的橋梁，但通過(guò)DDD，技術(shù)同學(xué)也更關(guān)注業(yè)務(wù)，真正做到產(chǎn)研融合。

1）問(wèn)題域分析領(lǐng)域建模

• 分治思維
• 模型思維
• 抽象思維
• 結(jié)構(gòu)化思維

2）模型實(shí)現(xiàn)

• 簡(jiǎn)單思維
• 契約思維
• 解耦思維

3.DDD帶來(lái)的優(yōu)劣勢(shì)及建議

1）優(yōu)勢(shì)

• 隱性知識(shí)顯性化，統(tǒng)一團(tuán)隊(duì)語(yǔ)言
• 圍繞業(yè)務(wù)變化，隔離“變化”
• 積木式組合業(yè)務(wù)演進(jìn)
• 關(guān)注點(diǎn)分離，隔離技術(shù)細(xì)節(jié)
• 面向測(cè)試、運(yùn)維
• 業(yè)務(wù)思維（主動(dòng)向前看業(yè)務(wù)，主動(dòng)提想法，0.5PM）

2）劣勢(shì)

• 團(tuán)隊(duì)上手有門檻（概念-理解-困惑-深入理解）

3）使用建議

• 業(yè)務(wù)場(chǎng)景復(fù)雜
• 業(yè)務(wù)變化頻繁
• 重點(diǎn)核心業(yè)務(wù)領(lǐng)域
• 可部分取用（分層思想、聚合、限界、架構(gòu)設(shè)計(jì)、解耦思維等）
• 團(tuán)隊(duì)共識(shí)即正確    

業(yè)務(wù)架構(gòu)是領(lǐng)域，技術(shù)架構(gòu)是容器，脫離靈魂的容器是沒(méi)有技術(shù)意義的。

Q&A

Q1：DDD重構(gòu)時(shí)，如何協(xié)調(diào)產(chǎn)品上線需求的矛盾？

A1：首先，我們進(jìn)行DDD重構(gòu)的時(shí)候，背靠公司技術(shù)中心的戰(zhàn)略，公司是鼓勵(lì)和倡導(dǎo)的；其次，重構(gòu)模式包括修繕者、絞殺者、演進(jìn)式。面臨與產(chǎn)品上線需求的矛盾時(shí)，我們可以選擇絞殺者，另起爐灶來(lái)優(yōu)化重構(gòu)，在原有業(yè)務(wù)中也不影響產(chǎn)品新需求接入。

Q2：選擇COLA架構(gòu)作為DDD重構(gòu)業(yè)務(wù)模型的原因是什么？

A2：首先，COLA是阿里開(kāi)源的，大廠背書，信任度較高；其次，COLA具備很好的分層架構(gòu)和規(guī)范，項(xiàng)目Github中提供了最佳實(shí)踐。如果初期不清楚如何進(jìn)行重構(gòu)，可以直接參考官方demo，將其映射到自己的業(yè)務(wù)中，后期再加入自身見(jiàn)解，進(jìn)行系統(tǒng)優(yōu)化。

作者介紹

李全黨，2021 年加入去哪兒網(wǎng)，擔(dān)任酒店供應(yīng)鏈代理商和基礎(chǔ)信息業(yè)務(wù)負(fù)責(zé)人、業(yè)務(wù)架構(gòu)SIG成員，擁有 10 年以上系統(tǒng)研發(fā)和軟件架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)主導(dǎo)搭建多個(gè) DDD 項(xiàng)目，有高并發(fā)、分布式服務(wù)、高可用的建設(shè)優(yōu)化經(jīng)驗(yàn)。

朱浩曼，2021年9月加入去哪兒網(wǎng)，擔(dān)任標(biāo)準(zhǔn)代理商業(yè)務(wù)負(fù)責(zé)人、業(yè)務(wù)架構(gòu)SIG成員。