DDD如何落地:去哪兒的DDD架構實操之路

文章很長,且持續更新,建議收藏起來,慢慢讀!瘋狂創客圈總目錄 博客園版 爲您奉上珍貴的學習資源 :

免費贈送 :《尼恩Java面試寶典》 持續更新+ 史上最全 + 面試必備 2000頁+ 面試必備 + 大廠必備 +漲薪必備
免費贈送 :《尼恩技術聖經+高併發系列PDF》 ,幫你 實現技術自由,完成職業升級, 薪酬猛漲!加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷1)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷2)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷3)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領

免費贈送 資源寶庫: Java 必備 百度網盤資源大合集 價值>10000元 加尼恩領取


DDD如何落地:去哪兒的DDD架構實操之路

尼恩說在前面

在40歲老架構師 尼恩的讀者交流羣(50+)中,最近有小夥伴拿到了一線互聯網企業如阿里、滴滴、極兔、有贊、希音、百度、網易、美團的面試資格,遇到很多很重要的面試題:

談談你的DDD落地經驗?

談談你對DDD的理解?

如何保證RPC代碼不會腐爛,升級能力強?

微服務如何拆分?

微服務爆炸,如何解決?

你們的項目,DDD是怎麼落地實操的?

所以,這裏尼恩給大家做一下系統化、體系化的梳理,使得大家可以充分展示一下大家雄厚的 “技術肌肉”,讓面試官愛到 “不能自已、口水直流”

也一併把這個題目以及參考答案,收入咱們的 《尼恩Java面試寶典PDF》V123版本,供後面的小夥伴參考,提升大家的 3高 架構、設計、開發水平。

最新《尼恩 架構筆記》《尼恩高併發三部曲》《尼恩Java面試寶典》的PDF,請關注本公衆號【技術自由圈】獲取,後臺回覆:領電子書

除了本文,尼恩輸出了一個 《從0到1,帶大家精通DDD》系列,幫助大家徹底掌握DDD,鏈接地址是:

阿里DDD大佬:從0到1,帶大家精通DDD

阿里大佬:DDD 落地兩大步驟,以及Repository核心模式

阿里大佬:DDD 領域層,該如何設計?

極兔面試:微服務爆炸,如何解決?Uber 是怎麼解決2200個微服務爆炸的?

阿里大佬:DDD中Interface層、Application層的設計規範

字節面試:請說一下DDD的流程,用電商系統爲場景

大家可以先看前面的文章,再來看本篇,效果更佳。

另外,尼恩會結合一個工業級的DDD實操項目,在第34章視頻《DDD的頂奢面經》中,給大家徹底介紹一下DDD的實操、COLA 框架、DDD的面試題。

本文目錄

去哪兒網 DDD架構實操之路

作者介紹

李全黨,2021 年加入去哪兒網,擔任酒店供應鏈代理商和基礎信息業務負責人、業務架構SIG成員,擁有 10 年以上系統研發和軟件架構設計經驗主導搭建多個 DDD 項目,有高併發、分佈式服務、高可用的建設優化經驗。

朱浩曼,2021年9月加入去哪兒網,擔任標準代理商業務負責人、業務架構SIG成員。

分享概要

一、架構設計理念與技術

二、業務系統重構背景

三、系統重構改造模式和架構選擇

四、業務驅動的微服務架構演進實踐

五、總結和思考

六、Q&A

一、架構設計理念與技術

1. 架構演變路徑

  • 單體(又稱巨石系統):將所有業務集成在一個系統中。在項目的早期階段,企業通常會選擇單體架構以降低運營等成本。
  • 服務化:隨着業務的快速發展和流量增長,進入服務化階段。這個階段包括服務拆分、治理和模型抽象。
  • 平臺化:在業務膨脹期過後,服務化維護成本上升,服務粒度過於細分,重複開發等問題暴露,因此走向平臺化(服務能力積累、服務整合、領域自治等)。
  • 中臺化:構建企業級能力複用平臺,是平臺化的下一步,具備數據互通能力和業務變化高響應力。

這種業務架構的演變路徑,從側面反映了互聯網企業的演變路徑。每種架構的好壞並非絕對,選擇與否,僅取決於是否適應當前和可預見的未來。

本次分享主要介紹服務化到平臺化的過程,即從服務細粒度到領域能力積累的演進過程。

2. 架構設計理念

以業務爲中心、適應業務變化是架構設計成功的關鍵。指導業務架構設計的維度包括:

1)商業模式及成熟度

傳統行業的業務相對穩定和成熟,非必要情況下建議構建單一服務。如需拆分,建議將變化頻繁和不頻繁的業務拆分。

互聯網行業分爲初創公司和成熟穩定的公司:

  • 初創、商業不穩定的公司:需要多種業務快速試錯,可採用微服務。通過微小的單體服務器,快速構建探索場景,以技術的確定性應對未來發展的不確定性。例如,去哪兒網的某些團隊在制定簡單方案後,可使用微服務獲取市場反饋,快速驗證效果。

  • 商業穩定或固化的公司:不再需要技術端的靈活性,也不願承擔靈活性帶來的架構維護成本,此時可以考慮合併微服務,以降低運營成本。

目前旅遊行業已相對穩定,去哪兒網符合上述第二種情況,可以考慮將之前拆分過細的微服務進行合併。這也是去哪兒網架構演進的原因之一,原有業務拆分過細,達到人均10個應用,維護成本極高。

2)面向業務的變化

  • 組件設計圍繞業務變化
  • 組件調用非強依賴
  • 組件業務複用
  • 組件顆粒度與成熟度

爲快速適應業務變化,需識別業務核心問題,明確業務邊界,實現業務組件的最大化複用;區分變化與不變的業務,將變化限制在一定範圍內,從而降低影響。

面向業務變化與不變的情況下,組件顆粒度要拆分到什麼程度?

組件拆分粒度過細時,可複用性強,但組裝複雜;拆分粒度過大時,使用方便,但應用場景有限。

3)技術延遲決策

《架構整潔之道》一書提到:“良好的架構設計應關注用例,並將它們與其他周邊因素隔離。”

在前期,應關注用例,後期再決策具體技術。

4)康威和逆康威定律

  • 康威定律:產品的形態無意識地映射了其組織溝通的格局。系統的構建本質上覆制了公司的組織架構,而系統各部分之間的接口則展現了公司各部門間的信息傳遞與合作方式。
  • 逆康威定律:當前組織效率不夠高時,可以優先進行系統設計,利用系統設計來逐步優化後的組織架構。例如,去哪兒網在 2021 年實施了內部領域驅動設計,外部 API 的戰略,對團隊和職責進行了合理劃分,這就是逆康威定律的一個實踐案例。

5)面向測試、運維

測試是確保系統質量的關鍵環節,採用測試驅動開發(TDD)來驗證架構的合理性、可隔離性和易測試性。

6)軟件質量屬性

在開發和運行階段,軟件質量特性表現爲可用性、可維護性、性能、安全性、易用性等。

以功能性爲核心進行架構設計,依據質量特性進行增量式的迭代重構和優化。

上圖是架構的一些關鍵技術,這張圖的粒度較粗。

從下往上觀察,公司底層主要由容器和自動化技術支持,上層則是監控和治理、前後端分離的系統。

根據這張圖,領域驅動設計(DDD)成爲整個架構的指導原則。

二、業務系統重構背景

1. 業務介紹:酒店基礎信息

上列四張圖簡單展示了去哪兒網本次重構的主題,也是酒店基礎信息部所負責的業務。

  • 列表頁:用戶打開 APP,輸入目的地和入住時間,點擊搜索,便會轉到列表頁,展現搜索地點的所有酒店列表信息。
  • 詳情頁:點擊希望入住的酒店,即可進入詳情頁。
  • 酒店Info:點擊酒店名字,則可進入酒店Info頁。
  • 進訂頁:用戶決定預定酒店房間後,就跳轉到進訂頁。

2. 基礎信息業務架構

注意:請點擊圖像以查看清晰的視圖!

上圖展示了酒店基礎信息業務對應的架構。

去哪兒網售賣的酒店,來源於各個代理商和集團分銷的信息,按照圖示自下到上,經過基礎層,然後到達基礎信息部門的主要業務層。

業務層最重要的內容是酒店聚合,包括代理商酒店Tree和Q物理酒店。

我們將各個代理商提供的酒店信息,按照一定業務邏輯規則,聚合到去哪兒網的Q側物理酒店,並將這部分信息對外銷售,以優化用戶體驗。

爲什麼能夠提升用戶體驗?

舉個例子,比如現在投放的是季楓酒店,A代理商將其稱爲季楓酒店北京店,B代理商將其稱爲季楓酒店北京中關村店,C代理商稱之爲季楓酒店北京中關村蘇州街店,用戶容易混淆。

因此,去哪兒網將各代理商提供的酒店信息,按照一定的業務邏輯、規則整合爲外部可見的唯一物理酒店。

酒店Tree的含義是,每個代理商投放的酒店,對應到去哪兒網的酒店,以去哪兒網的酒店爲根,下方掛接不同代理商投放的酒店信息,形成對應關係。

目前,我們團隊的核心業務是將基於業務層的酒店信息,提供給應用層,如 APP 搜索或篩選時展示的信息。

3. 落地技術中心戰略,償還技術債務

旅遊業可能是受疫情影響最大的行業之一。在此背景下,技術中心在 2022 年提出了“鞏固效率之本,分擔產品之憂”的戰略,從而開啓了領域驅動設計(DDD)的重構之旅。

如上圖,重構前,業務和業務架構存在以下問題:

  • 數據寫入鏈路長:缺乏核心業務的統一出口,數據更新不夠及時。由於沒有實時查詢能力,其他團隊在調用數據時,需要先拉取並自行緩存。
  • 核心業務入侵:產品需求交付效率不高,一個產品需求可能需要對五個微服務進行調整。
  • 核心業務分散:圖中灰色條塊代表着我們的核心業務,它受到整個鏈路的耦合影響,分散在各個系統中,導致核心業務遭受侵入。

爲了解決這些問題,技術中心決定採用領域驅動設計(DDD)進行系統重構。通過這一方法,我們希望能夠提高產品需求交付效率,縮短數據寫入鏈路,以及降低核心業務受到的侵入程度。此外,DDD 還能夠幫助我們實現核心業務的模塊化,使得各個系統之間的耦合度降低,從而提高整個系統的靈活性和可擴展性。

4. 系統重構模式選擇

沒有最好的架構,只有最合適的架構。

以下是備選的系統重構模式:

  • 修繕者:在現有系統基礎上,新增一層抽象層,確保對外服務能力不變,然後對內部進行優化改造。

  • 絞殺者:修繕沒有辦法適應現狀的情況下,需要另起爐竈,在外部構建新功能,逐步剝離原有邏輯。爲新功能提供服務,逐步淘汰或重構各個需下線的服務。在重構過程中,要權衡顛覆者的優缺點。

  • 優點:不影響原有業務,一旦條件成熟,新系統可完全替代舊系統。

  • 缺點:在一段時間內需要維護兩套系統,付出額外的開發維護成本。

  • 演進式:對於老項目邏輯模糊的情況,採用演進式迭代。識別老系統中的核心業務邏輯,從最小可行性產品(MVP)版本開始,快速迭代核心業務,率先上線觀察效果,然後逐步將剩餘的邊緣業務切換過來,並及時調整。

  • 優點:控制迭代風險,避免全面替換系統,降低不可預測的影響。

三、系統重構改造模式與架構選擇

前文講解了架構的演變路徑、理念及改造模式的選擇,最終衍生出來的系統重構框架是什麼樣子?

系統重構模式選擇

以業務爲導向,適應業務變化是現代架構設計成功的核心要素,而領域驅動設計(DDD)的理念恰恰符合這一成功架構設計的原則。

1)服務業務戰略

站在EA(企業架構)角度(包括業務架構 BA、應用架構 AA、數據架構 DA、技術架構 TA)的角度出發,DDD 能夠將業務架構與應用架構相結合,將問題領域與應用架構分離。通過分解業務架構中的“價值流 + 業務能力”,實現能力的下移。同時,根據 DDD 劃分的限界上下文和聚合,構建應用架構,實現自下而上的“高內聚、低耦合”。

2)演進式架構

DDD 的核心思想包括:

  • 戰略層面:業務問題分析→分解子問題域,識別核心域→分而治之,降低業務複雜度;
  • 戰術層面:識別問題域的不同業務上下文→領域建模,定義聚合,組件化業務需求→指導微服務的拆分;
  • 實現層面:利用成熟的分層模式、依賴倒置屏蔽掉技術細節複雜度,通過DDD方法設計的微服務,不僅可以通過限界上下文和聚合實現微服務內外的解耦,同時也可以很容易地實現業務功能積木式模塊的重組和更新,從而實現架構演進。

總之,自上而下地拆解業務,並以此爲指導,自下而上地構建模型,最終達到高內聚低耦合的狀態。

在系統重構過程中,我們選擇了絞殺模式和演進模式。鑑於系統複雜度高,瞭解業務細節的人員較少,爲了降低重構對現有業務的影響,我們將核心資源投入到核心業務中,快速上線以觀察效果。以下將詳細介紹演進實踐。

四、以業務驅動的微服務架構演進實踐

1. 領域驅動設計過程

上圖是以業務驅動的微服務架構演進的實戰過程,介紹DDD的完整流程和關鍵路徑。

進行領域驅動設計時,需要對組內成員進行定位。

最重要的是識別領域專家,即那些對特定領域有深入認知的人,他們能幫助團隊成員更好地理解業務,有利於後續的頭腦風暴和建模過程;其次是技術專家和開發團隊。

領域驅動設計的關鍵路徑如下:

第一步,領域專家與開發團隊針對具體問題,明確業務願景,探討需求,從而確立統一的語言,積累領域知識。統一語言意味着對問題領域內的概念達成共識,例如,團隊成員對某個詞語的定義有明確的認識,沒有歧義,從而降低溝通成本。

第二步,分析問題域並劃分子域(比如核心子域、支撐子域、通用子域),進而劃分限界上下文,構建上下文地圖。

第三步,領域建模並實現模型。將以上兩步分析,映射到代碼層面,進行模型實現。這一步驟可以概括爲“兩關聯一循環”。“兩關聯”指的是統一語言與模型之間的關聯,以及模型與軟件實踐之間的關聯。“一循環”意味着在實踐過程中,可能會遇到各種困難和不確定性,需要在不斷迭代的過程中提煉知識,最終趨近於完美的模型。

總之,領域驅動設計是一個動態迭代的過程,通過明確團隊成員的角色,發掘領域專家,建立統一語言,分析問題領域,進行建模和實踐,不斷優化和完善模型。在這個過程中,團隊成員需要密切合作,充分發揮各自專長,共同推動領域驅動設計取得成功。

2. 基於DDD落地實踐

上圖展示了基於DDD落地實踐的過程。

首先是定位願景,其重要性在於決定了後續的發展道路;

其次,分析問題域中的現有業務場景;

然後,根據劃分的子域,識別限界上下文;

最後,在限界內進行領域建模和實現模型。

1)問題域分析

① 定位願景

麥肯錫提出“電梯演講”概念是指,在乘坐電梯的30秒之內,向顧客清晰準確地解釋解決方案,即使用簡短的語言精準說明業務價值。

比如,去哪兒網的核心價值是“總有你要的低價”。因此,所有核心工作都應圍繞低價展開。落實到基礎信息團隊,我們的願景就是提供豐富的信息聚合。

② 明確領域專家

由於產品迭代頻繁,系統演進缺乏領域專家。因此,按照產品、QA、技術人員的順序來確立領域專家。

爲了分析原有項目中,哪些用戶用例與我們的願景密切相關,我們整理了用例圖,並安排同學逐一分析。

分析結果顯示,經過多年的迭代,許多業務已經不再使用,舊業務無法適應現有的商業模式。

因此,我們將這些業務下線或重新分配資源,最終將 188 個用例精簡爲 79 個,大大簡化了工作內容。

③ 事件風暴

事件風暴主要關注三個方面:識別領域事件、識別決策命令、識別領域名詞。

事件風暴的輸出將作爲後續領域建模的輸入,需要遵循以下原則:

  • 業務視角事件:從業務視角分析領域事件,例如,某個業務操作產生特定數據,引發業務流程狀態變化,並向外發送消息。在進行頭腦風暴時,技術人員容易陷入代碼細節,而忘記最初的目標。
  • 先發散,再收斂:首先列出所有想法,然後在基礎上進行收斂。
  • 決策命令: 分析導致事件發生的人員和動作。

④ 統一語言

沒有 DDD 經驗的同學可能會問,什麼可以作爲統一語言?

答案是,什麼都可以作爲團隊的統一語言。

例如,如果一個老系統的內部邏輯複雜且難以理解,重構成本高,不易修改,可以將這部分代碼作爲團隊內部的統一語言。這樣一來,產品和技術的同學都瞭解老系統的目標、能力和應對策略。

由於技術同學在描述事物時偏向於使用代碼邏輯,這可能導致與產品同學的溝通出現偏差。

在這種情況下,統一語言可以拉近雙方的認知差距。技術同學只需拋出幾個領域名詞,產品同學就能理解。

需要注意的一點是,統一語言的術語表應包含中英文對照,以便在後期編碼和解碼過程中,在代碼層面實現認知統一。

2)識別限界及子域劃分

識別限界上下文的總體原則是先業務後技術,上圖展示了領域層面的劃分流程。

  • 降低技術複雜度:根據限界上下文承受的流量不同,我們通過創建彈性邊界、部署和可用性測試,採用不同方法對待不同的限界上下文。

  • 降低管理複雜度:基於領域層劃分的業務邊界會影響工作邊界的劃分。上述提到的康威定律和兩個披薩原則(一個高效的技術研發團隊,最佳團隊規模應控制在能喫兩個披薩的人數)都對工作邊界具有指導意義。

  • 降低業務複雜度:在業務層面,要消除語言的歧義。例如,在去哪兒網內部,商務和技術團隊可能對“酒店”這個詞彙的理解有所不同,因此在確定限界上下文時要避免這種情況。

限界上下文的特徵

  • 獨立進化原則:對外提供穩定接口,內部變化不影響外部。
  • 穩定空間原則:外部變化不會影響自治單元。
  • 自我履約原則:自治單元自行決定職責。例如,在進行代理商酒店數據抓取時,無需進行後續解析。
  • 最小完備原則:自治單位職責完整,無需向其他自治單位求助以獲取自身信息。

在繪製上下文依賴地圖時,要遵循三不原則:避免雙向依賴、循環依賴和過長依賴。

如上右圖所示,我們在製作上下文依賴地圖時,我們發現酒店解析依賴酒店抓取,酒店抓取依賴酒店聚合信息,酒店聚合信息依賴靜態信息,靜態信息依賴酒店解析出的數據,形成循環依賴。因此,劃分方式不合適。針對這種情況,我們創建了“酒店上下文”環節,打破循環依賴。

在限界上下文後,需要識別核心域、支撐域和通用域,劃分參考是與業務願景的相關性。

識別子域的好處是,對外可以明確告知自身核心競爭力;對內可以明確人員、設備資源分配,評估產品需求優先級以及是否處於核心領域。

3)領域建模

根據事件風暴和限界上下文的輸出,我們可以構建領域模型。

① 建模意義

  • 使用聚合表達業務的“高內聚,低耦合”特性;
  • 降低業務複雜度,以便更好地應對業務變化。

② 建模過程

  • 識別實體、值對象、豐富領域邏輯
  • 定義聚合、識別聚合根

在建模過程中,最棘手的問題在於如何把握尺度,也就是判斷哪些方法應被納入模型,哪些屬性應置於哪個模型。我個人認爲,只要在團隊內達成共識,無論實際結果如何,都可以視爲正確。因爲建模是一個不斷優化的過程,隨着對業務理解的深入,要推翻之前的結論並一次性構建完美模型較爲困難。

在分層架構中,領域層和業務層都應存在。若盲目將功能和用例納入領域層,可能導致領域層過於龐大,進而影響其可重用性和業務表達力。因此,我們需要正視模型和領域能力的不確定性,逐步採取迭代方式,將能力下沉至領域模型中。

③ 建模原則

  • 重點關注核心域建模:投入核心資源
  • 聚合儘量小,適應業務變化
  • 聚合邊界內強一致性
  • 抽象模型,防止過多屬性拍平(DP):屬性被拍平的弊端是,模型內字段太多,無法識別識別模型。

上圖展示了兩個原則:共性業務能力優先下沉到領域,共性技術問題抽象成業務。

沒有完美的模型,也沒有正確的模型,領域模型的共識即爲正確。因此,團隊的整體能力決定了模型完美程度的上限。提供一個參考的檢驗技巧:在建立完模型後,可以使用業務場景檢驗模型的完整度。如此循環往復,模型將逐漸完善。

④ 落地實踐時劃分微服務

如上所示,業務邊界、康威定律、業務變更頻率、彈性邊界、技術選型等,都可作爲劃分依據。

需要指出的是,一個微服務可以包含多個限界上下文,但只能包含一種子域類型(核心、通用、支撐),不能將核心域和支持域放在同一微服務中。如果支持域的可用性不佳,可能會影響核心邏輯,因此可能爲這個問題付出沉重代價。

4)模型實現

① 業務流程和領域模型映射

如上所示,業務流程或業務用例包含多個階段,每個階段又包含一系列活動。我們將這些業務活動與整個分層架構相結合,構建相應的映射關係。

建立映射關係的好處在於,在分層架構和領域模型高度凝聚、完善的情況下,便於後續需求的接入和擴展。從上到下分解業務流程,進行分層映射,技術負責度得以隔離。

② 模型映射代碼清單

如上圖所示,應用層、領域層、基礎設施層是領域對象的聚合,模型映射代碼清單明確了每個層次的能力、領域層的領域對象、是否存在前置依賴對象,以及包名、類名和方法名。這些內容與前面提到的中英文對照表相對應。

構建這份代碼清單有助於團隊內部協作,提高開發效率;爲新成員提供參考,快速瞭解項目核心邏輯和能力。

③ COLA應用架構

在開發階段,我們採用了 COLA 開源框架,其分層架構包括適配層、領域層、應用層和基礎設施層。

無論是 COLA 還是 DDD 的分層架構,都圍繞業務核心,基於穩定的領域模型,對外提供領域能力。

選擇COLA的原因如下:

  • 定義良好的分層結構、規範;
  • 層內部結構“聚合分包,功能分類”;
  • 提供了實用的應用架構最佳實踐:《領域驅動設計》一書主要提供設計思想,而 COLA 則爲實際應用提供了可借鑑的模板。

下圖是我們內部基於COLA架構落地微服務的實踐。

  • Adaptor:多端適配

  • Client:業務提供的接口,比如Dubbo

  • APP:業務用例Case的編排,含executor、publish、qschedule等

  • Domain(聚合、實體、值對象的定義)

    • 業務規則顯式化,包括邏輯判斷和對象設值代表的含義,純內存操作;
    • 實體(Entity):解決單個對象的邏輯變更,領域服務解決多對象的業務邏輯變更;
    • 領域服務(Domain Service):處理多個對象的業務邏輯變更;
    • 限制:不允許跨聚合調用;
    • 特點:充血模型
  • Insfrastructure:Repisitory實現;ACL的定義和實現

  • Common:提供公共屬性、工具類,由domain調用

通過運用 COLA 框架,我們希望實現業務核心的模塊化,提高系統的可擴展性和靈活性。在實際開發過程中,團隊成員需遵循分層設計原則,緊密協作,不斷積累和共享領域知識,共同推動項目的成功。

上圖是對前一張圖的具體描述,我們採用了 CQRS 模式,即命令與查詢職責分離。

前文的一張圖描述了架構重構前的狀況:核心業務分散在各個服務中,沒有得到收斂和整合,業務耦合度較高。通過限界劃分和領域建模,我們實現了業務的分離。

在改造前,系統缺乏實時查詢功能,各團隊將數據拉回並本地緩存。經過重構,我們採用了異步調用機制,實現了數據持久化,並對外提供查詢功能。

在重構前,系統沒有提供實時查詢能力,各團隊將數據拉走並進行本地緩存。重構後,基於異步調用機制,實現了數據持久化,並對外提供查詢功能。

④ 領域模型與代碼模型映射

上圖是領域模型與代碼模型的映射。分層對應上一張圖展示的架構,在 Domain 層,根據領域劃分進行聚合分包。圖中標藍的 Hoteltree 就是前文提到的酒店聚合,在該領域內進行功能劃分。

Domain Primitive 是 Value Object 的進階版,它在原始 VO 的基礎上要求每個 DP 擁有概念的整體,而不僅僅是值對象。在 VO 的不可變基礎上增加了有效性(Validity)和行爲。

DP 特徵如下:

  • 擁有完整的概念整體,精準定義
  • 使用業務域中的原生語言
  • 業務域的最小組成部分,可構建複雜合
  • 隱式轉顯式

例如,聯繫信息對外顯示爲電話號碼,但背後隱藏了區號、國內外來源等隱式屬性。通過 DP,我們可以找出這些隱式屬性並將其轉化爲顯式,這是推薦使用 DP 的關鍵原因之一。

通過以上映射,我們希望實現領域模型的清晰劃分,降低業務耦合度,提高系統的可擴展性和靈活性。在實際開發過程中,團隊成員應緊密協作,不斷積累和共享領域知識,共同推動項目的成功。

在架構重構之前,系統核心業務分散在各個服務中,耦合度較高。通過限界劃分和領域建模,我們實現了業務的分離。重構後,系統具備了實時查詢功能,數據持久化,並對外提供查詢服務。在這個過程中,團隊遵循分層設計原則,緊密協作,不斷積累和共享領域知識,共同推動項目的成功。

五、總結和思考

1. 項目落地效果

1)組織效率

  • 組織資源是否集中在了核心業務領域;

  • 是否能用統一語言溝通描述業務,體現在需求評審、站會等有關會議的效率上;

  • 領域知識是否得到沉澱,是否有人能承擔“領域專家”;

  • 團隊間職責模糊地帶少,相互扯皮的機會少。

2)開發效率

  • 模塊粒度是否合適、模塊間依賴是否健康;
  • 接口數量是否穩定,不膨脹;
  • 因爲功能理解不足引起的bug數量是否低;
  • 模塊和接口的自測性程度高不高;
  • 代碼可讀性,人員交接和新人上手是否足夠快。

3)鞏固效率之本,分擔產品之憂

  • 清晰領域,核心子域重點投入;
  • 統一語言,減少產運研測溝通成本,增加2名研發業務專家;
  • 承接產品需求75%,助力0.5PM;
  • 21個應用微服務,通過DDD領域劃分後下降到13個,微服務減少33%;
  • 開發工時3pd以下產品響應效率提升52.3%,3pd以上32.5%,QA工時下降62.3%;
  • 架構、聚合分層,功能分類,新人上手快

2. 思維模型改變

技術團隊從被動了解業務轉變爲主動了解業務,解讀業務策略變化,爲其定義測量,提出數字化方案。產品經理的核心價值是成爲技術與業務之間的橋樑,但通過 DDD,技術同學也更加關注業務,實現產研融合。

1)問題域分析領域建模

  • 分治思維
  • 模型思維
  • 抽象思維
  • 結構化思維

2)模型實現

  • 簡單思維
  • 契約思維
  • 解耦思維

3. DDD帶來的優劣勢及建議

1)優勢

  • 隱性知識顯性化,統一團隊語言
  • 圍繞業務變化,隔離“變化”
  • 積木式組合業務演進
  • 關注點分離,隔離技術細節
  • 面向測試、運維
  • 業務思維(主動向前看業務,主動提想法,0.5PM)

2)劣勢

  • 團隊上手有門檻(概念-理解-困惑-深入理解)

3)使用建議

  • 業務場景複雜
  • 業務變化頻繁
  • 重點核心業務領域
  • 可部分取用(分層思想、聚合、限界、架構設計、解耦思維等)
  • 團隊共識即正確

業務架構是領域,技術架構是容器,脫離靈魂的容器沒有技術意義。

Q&A

Q1:DDD重構時,如何協調產品上線需求的矛盾?

A1:首先,我們在進行 DDD 重構時,要依託公司技術中心的戰略,公司對此表示鼓勵和倡導;其次,重構模式包括修繕者、絞殺者、演進式。面臨與產品上線需求的矛盾時,我們可以選擇絞殺者,重新構建優化,在原有業務中也不會影響產品新需求的接入。

Q2:選擇COLA架構作爲DDD重構業務模型的原因是什麼?

A2:首先,COLA 是阿里開源的,具有大廠背書,可信度較高;其次,COLA 具備優秀的分層架構和規範,項目 Github 中提供了最佳實踐。如果初期不確定如何進行重構,可以直接參考官方 demo,將其映射到自己的業務中,後期再加入自身見解,進行系統優化。

說在最後

DDD架構如何落地,是是非常常見的面試題。

以上的內容,如果大家能對答如流,如數家珍,基本上 面試官會被你 震驚到、吸引到。

在面試之前,建議大家系統化的刷一波 5000頁《尼恩Java面試寶典PDF》,並且在刷題過程中,如果有啥問題,大家可以來 找 40歲老架構師尼恩交流。

最終,讓面試官愛到 “不能自已、口水直流”。offer, 也就來了。

當然,關於DDD,尼恩即將給大家發佈一波視頻 《第34章:DDD的頂奢面經》, 幫助大家徹底穿透DDD。

技術自由的實現路徑:

實現你的 架構自由:

喫透8圖1模板,人人可以做架構

10Wqps評論中臺,如何架構?B站是這麼做的!!!

阿里二面:千萬級、億級數據,如何性能優化? 教科書級 答案來了

峯值21WQps、億級DAU,小遊戲《羊了個羊》是怎麼架構的?

100億級訂單怎麼調度,來一個大廠的極品方案

2個大廠 100億級 超大流量 紅包 架構方案

… 更多架構文章,正在添加中

實現你的 響應式 自由:

響應式聖經:10W字,實現Spring響應式編程自由

這是老版本 《Flux、Mono、Reactor 實戰(史上最全)

實現你的 spring cloud 自由:

Spring cloud Alibaba 學習聖經》 PDF

分庫分表 Sharding-JDBC 底層原理、核心實戰(史上最全)

一文搞定:SpringBoot、SLF4j、Log4j、Logback、Netty之間混亂關係(史上最全)

實現你的 linux 自由:

Linux命令大全:2W多字,一次實現Linux自由

實現你的 網絡 自由:

TCP協議詳解 (史上最全)

網絡三張表:ARP表, MAC表, 路由表,實現你的網絡自由!!

實現你的 分佈式鎖 自由:

Redis分佈式鎖(圖解 - 秒懂 - 史上最全)

Zookeeper 分佈式鎖 - 圖解 - 秒懂

實現你的 王者組件 自由:

隊列之王: Disruptor 原理、架構、源碼 一文穿透

緩存之王:Caffeine 源碼、架構、原理(史上最全,10W字 超級長文)

緩存之王:Caffeine 的使用(史上最全)

Java Agent 探針、字節碼增強 ByteBuddy(史上最全)

實現你的 面試題 自由:

4800頁《尼恩Java面試寶典 》 40個專題

免費獲取11個技術聖經PDF:

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章