DDD神藥:去哪兒結合DDD, 實現架構大調優

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

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

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


DDD神藥:去哪兒結合DDD,實現架構大調優

尼恩說在前面

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

談談你的DDD落地經驗?

談談你對DDD的理解?

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

微服務如何拆分?

微服務爆炸,如何解決?

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

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

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

《尼恩 架構筆記》《尼恩高併發三部曲》《尼恩Java面試寶典》的PDF,請到公衆號【技術自由圈】獲取

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

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

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

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

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

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

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

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

DDD落地:從騰訊視頻DDD重構之路,看DDD極大價值

DDD落地:從美團抽獎平臺,看DDD在大廠如何落地?

美團面試:微服務如何拆分?原則是什麼?

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

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

DDD現在非常火爆,是有其巨大生產價值,經濟價值的, 絕不僅僅是一套概念那麼簡單。

DDD的絕大價值,具體請參見以下視頻:

從騰訊視頻DDD重構案例,看看DDD極大價值

本文目錄

1、案例簡述

作者:鄭吉敏,2019年8月入職去哪兒網,機票目的地事業羣技術總監、技術委員會委員、業務架構 SIG 負責人,負責酒店報價中心團隊、業務架構組。

2020 年疫情對旅遊行業影響特別大,公司層面進行了組織架構的調整,酒店業務也經歷了深刻的變革。在新的業務團隊着手推進實際需求時,他們遇到了產研效率的新問題,主要表現爲產品研發需要與多個技術團隊協作,導致整體技術架構與業務發展失去同步。

鑑於之前領域驅動設計(DDD)的成功實踐,酒店技術部門在2021年中旬主動發起了一次以DDD爲指導思想的技術架構戰略調整,包括組織架構和系統架構的優化,並設定了一系列核心技術方案的規範。本次將重點闡述這次戰略調整的確認和實施過程。通過對這次戰略調整的剖析,我們可以看到康威定律和領域驅動設計思想在其中所起的關鍵作用。

2、案例背景及問題分析

背景

2020 年初,全球爆發了新冠疫情,對旅遊行業影響比較大。2020年5月,公司進行了重大調整,首先組建了機票目的地事業羣,將機票和酒店兩大事業部從獨立運營調整爲合併爲一個事業羣。此外,公司還對服務、用戶體驗等團隊進行了統一管理,使之對事業羣負責。同時,公司制定了機票與酒店業務交叉的戰略目標,旨在提高用戶購買機票後的酒店預訂體驗。

在面對這些組織架構和業務架構調整的同時,我們開始思考如何調整系統架構以支撐這些變化。帶着這個疑問,我們來探討實際過程中遇到的一些問題。

問題及表現

產品吐槽

  • 幾乎每個需求都需要與多個技術團隊溝通,合作過程繁瑣
  • 很多需求的技術方案經常需要升級,才能達成共識

引申問題

  • 一些看似簡單的需求,實際上涉及到的鏈路較長,總有團隊在無需修改邏輯的情況下也要進行透傳
  • 在討論技術方案時,不同團隊對於某個邏輯由誰來實現存在分歧,本質上是職責邊界不夠清晰

問題分析一

先來看一下主流程核心的交互:

(注:圖中 List 代表列表頁、Detail 代表詳情頁、Booking 代表預訂頁,Order 代表訂單頁)

通過上圖的交互流程,我們可以總結出以下幾個問題:

  • 所有核心流程都涉及的團隊是報價團隊,報價團隊是後端團隊,比較底層
  • 用戶端跨頁面交互的統一處理需要在底層的報價團隊完成
  • 底層修改,會帶動整個鏈路跟着修改(典型的比如:基礎數據新增字段)
  • 報價團隊的核心職責是根據用戶需求計算酒店房型、價格及優惠細節,而基礎數據和相關邏輯不需要過多關注

問題分析二

繼續看一下主流程核心團隊及核心設計:

通過上圖,我們可以總結出以下幾點:

  • 很多團隊在自己的領域層上面都有應用層
  • 這些應用層導致了一些任務上下游團隊都能完成
  • 而在衆多團隊都能承擔任務的情況下,可能會出現無人願意承擔的情況
  • “萬金油”式的架構在業務上升期較爲適用,不適合穩定期

3、案例分析與規劃

基於 Explicit Architecture(清晰架構)分析

上圖來自國外頂級架構師 herberto graca 的博客(https://herbertograca.com/),融合了 DDD、洋蔥架構、整潔架構、CQRS 的”清晰架構“,這個架構有很多優勢,比如:

  • 從外向內,越向內越偏核心原則,核心原則相對穩定。核心原則就是常規的領域層,提供核心能力
  • 外層基於核心原則適應不同業務場景,整合內層能力。這一外層主要包括接口層和應用層,主要使用主動適配器模式,重點關注 BFF 及對內層能力的聚合
  • 內層不依賴外層,不受業務變化而變化,關注能力的擴展,完成核心策略實現
  • 邊界明顯,尤其是領域層與應用層之間
  • CQRS 機制,耦合度低,通過外層整合內層能力,動態適應業務變化,提高擴展性

...

技術架構構想

結合清晰架構的特點來思考技術架構整體的調整策略

  • 核心思路:整體架構按照DDD分層架構進行,嚴格區分應用層和領域層

  • 核心動作:將包含核心領域的團隊各自的“應用層”交出,統一交給下游網關團隊,形成統一的應用層,這些團隊的工作將轉變爲一個個核心領域

技術架構調整規劃

圍繞上面的構想,整體架構圖期望如下圖所示:

通過上面這個圖可以明確幾個關鍵點:

明確戰略調整核心

  • 突出核心領域,壯大“大前臺”(內部稱爲主站,此處爲方便理解調整爲“大前臺”)

明確和之前的區別

  • 負責核心領域的團隊聚焦可複用能力,專注核心策略和玩法改進
  • 負責應用層的團隊關注業務識別與擴展,專注業務模型設計和整合下游能力
  • 業務收斂到一個團隊,這個團隊瞭解下游可提供的能力,能從全局角度看待業務開展

優勢劣勢分析

圍繞着上面的調整,分析一下優劣和劣勢

優勢(偏向中臺方向)

  • 減少影響團隊:很多需求,產品只需要對接前臺一個團隊即可,即上文提到的“大前臺”團隊
  • 減少數據鏈路:主流程鏈路變短,設計技術方案、出問題定位及解決都更容易,典型的就是基礎數據鏈路不再經過報價團隊給到下游

這兩點,在實際中都驗證了確實可以起到產研提效作用。

劣勢及可能帶來的問題

  • 短期內,已有的工作習慣發生變化:數據鏈路發生變化,需要多個團隊配合落地,然後適應新的鏈路,同時要適應新的架構
  • 可能帶來上游團隊人員不穩定:這將導致一些雜活完全交給“大前臺”,如果一些人長期從事雜活或小需求,可能會出現人員不穩定的問題。此時需要考慮爲這些人安排核心任務,改善業務建模等

4、案例落地過程

系統架構調整

  • 應用歸屬團隊調整
  • 已有邏輯歸屬調整

這裏主要完成的是,將做“應用層”的應用及邏輯上交給大前臺團隊,先保證各自團隊負責該負責的事情,讓負責核心領域的團隊實際主要負責領域的事情,其他交給大前臺

組織架構調整

  • 組織架構按需調整:比如多個網關合併成大前臺,同時藉助一些需求完成一些人員交叉
  • 核心人員歸屬團隊規劃:這裏主要是 review 一遍核心成員,看看適合領域團隊還是大前臺,必要時進行相關調整
  • HC 調整,招聘計劃跟進:本次會按需爲大前臺團隊增加 hc,同時加緊招聘節奏保證人員儘早就位,這樣也可以避免個別成員不穩定對整體的影響程度
  • 成立業務架構組:監督及保證架構調整,同時避免之後的腐化

技術方案標準制定

數據回傳標準化

  • SPU 維度:供應鏈 -> 基礎數據(商家、酒店等信息) -> 大前臺 -> 端

  • SKU 維度:供應鏈 -> 報價 (酒店房型及價格優惠,類比電商裏的商品) -> 大前臺 -> 端

依據 SPU、SKU 數據回傳標準進行鏈路優化:對比之前的鏈路,我們需要對基礎數據進行一次全面的改造。首先,我們基於 DDD 思想對基礎數據進行領域劃分,然後根據領域提供相應的對外 API 服務,直接對接大前臺。大前臺在接收報價團隊的應用層應用(內部名爲 mprice)時,將原有服務合併至現有應用層應用,並對接基礎數據服務 API。這樣,鏈路從之前的 7 個應用縮短至 4 個應用,同時將一些串行操作並行化,不但鏈路縮短了,同時主流程響應時間降低了 25%,效果特別好。

請求處理標準化

方案制定

上圖是我們主流程計算用戶支付價的幾個核心過程。重點解釋一下【商促】:基於用戶畫像打包,滿足特定要求(比如特定的用戶身份)的營銷活動,拿到更低的底價,獲得更高的利潤。

接下來討論一個實際問題:臨近節日,業務側希望解除某些商促限制,讓所有用戶均可享受。此時,技術方案該如何設計?我們給出兩種常規方案:

  • 前臺修改用戶身份,其他團隊不感知。該方案存在的問題:用戶身份本質上未發生變化,此時查看用戶身份會導致其他鏈路受到影響
  • 報價團隊識別場景,做特殊商促匹配。該方案存在的問題:報價團隊原本提供正常能力,現在需要提供定製化功能,與原有定位相差較大

這兩種常規方案均存在明顯問題。那麼,問題究竟出在哪裏呢?根本原因是標準方案中缺乏對【場景】的應對。

我們結合下圖聊一下業務場景中的身份和場景。

內部做了多次討論後,最終給出結論:

  • 身份:任意時刻下描述用戶(userid)不因此刻本身行爲及外部條件影響的自身描述性質或特徵的有限個數的標識
  • 場景:誰(who)在何時(when)何地(where)發生了什麼事件(what)產生了何種結果 or 情景(how)的標識

舉個例子,酒店新客戶和機酒用戶都是在一段時間內具有一定消費行爲(如購買酒店服務、機票等)的用戶。通過userid,我們可以直接明確地識別出他們,這屬於身份範疇。而“異地面紗”則是一個場景例子,因爲對於一個確定的userid,如果他的常住地爲北京,而這次要去其他地方,那麼“異地”這個條件才能得以滿足。需要注意的是,身份特徵的數量是有限的,比如門店新客戶,對於一個用戶來說,他是否是某個門店的新客戶通常是明確的。但是,如果我們有近百萬家門店,就不適合將其作爲身份標識,因爲在查詢userid時,列出每個門店的信息代價過大,這種更適合拿着 userid + 門店去查詢。

在我們的業務場景中,通常都是基於正常定義的身份進行標準計算。如果無法使用身份進行匹配,就需要藉助場景來解決問題。

基於對【身份】和【場景】的理解,針對前面的問題,我們給出更合理的方案:報價提供“強制使用指定商促能力”前臺識別場景,組裝使用新能力。這樣,報價仍然關注能力提升,前臺主要負責業務適應和組裝能力,核心是正確使用身份和場景。

補充說明一下,按照這樣架構調整及技術方案執行後,從整體來看整個架構:

  • 領域層能實際暴露出能力,應用層最終暴露出去功能
  • 由於應用層可以根據需求組裝各種能力,因此具備很高的擴展性;而對於領域層來說,它專注於能力的複用,因此更具穩定性
  • 應用層通過標準的身份和場景來組裝領域層的能力。要麼基於標準身份使用常規能力,要麼根據場景強制使用特殊能力
  • 功能是爲了解決實際場景需求而存在的,變化頻繁,因此需要提供衆多接口來實現定製功能。而能力則需要儘可能忽略場景,這樣才能實現最大程度的複用。爲了解決這兩者之間的矛盾,我們需要合理地使用身份和場景。

參數透傳

在日常開發過程中,我們經常會遇到需要將一個參數透傳給上游應用的情況。這種情況下,鏈路上參與透傳的團隊和應用往往不需要進行任何業務邏輯處理,卻增加了開發工作量,並影響了定義的API。爲了解決這個問題,公司內部的業務研發和基礎研發部門共同討論並確認開發了一個新的通用組件:QShareData。各個應用可以根據請求將數據寫入QShareData組件,相應的數據id會隨trace一起傳遞。鏈路上的其他應用可以根據需求通過數據id獲取其他應用寫入組件的數據,從而減少無意義的透傳。當然,這裏涉及到一些權限、性能和合理使用等問題,需要結合實際進行相應的限制和要求。

5、案例總結

首先,我們來回顧一下著名的康威定律:設計系統的組織,其產生的設計等同於組織之內、 組織之間的溝通結構。康威定律成立說明組織架構與系統之間必須匹配,但未強調合理。

接下來,我們再看一下 DDD 中的康威定律,它的核心觀點是系統架構主導組織架構。由於DDD立足於業務領域,迴歸業務本質,因此其與業務的契合度較高,更易於實現合理性。

有些人可能會疑惑:如何劃分團隊才能與業務緊密結合?其實,這個問題的本質在於讓DDD中的制約因素成爲需要改變的目標。爲此,我們可以從以下兩個方面着手:

  • 以DDD所提煉的業務領域模型爲基準,審視並調整組織架構,合理劃分團隊
  • 依據業務領域結構構建網狀組織架構,並在業務發生重大變化時保持組織架構的靈活性,從而使康威定律發揮反向作用

如此一來,我們便能更好地實現團隊與業務的匹配,推動組織架構和系統設計的協調發展。在這個過程中,康威定律爲我們提供了一種指導思想,幫助我們認識到組織架構與系統設計之間的相互影響關係。同時,通過領域驅動設計,我們能夠更加明確業務領域模型,從而調整組織架構,使其與業務發展相適應。

總之,要想實現團隊與業務的緊密結合,關鍵在於以DDD爲指導,審視組織架構,合理劃分團隊,並在業務變化時保持組織架構的靈活性。這樣,我們就能讓康威定律發揮積極作用,推動組織與系統設計的和諧發展。

說在最後

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:

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