隨著歷史業務不斷迭代和業務場景越來越復雜，攜程用車、租車（簡稱兩車）面臨歷史技術債和系統復雜度越來越高帶來的理解、維護、迭代困難等問題，我們開始尋求如何更有效的降低復雜度和提升效率的方法。

本文描述了兩車如何利用DDD（Domain-driven Design，領域驅動設計）方法論降低系統復雜度以及在重構歷史系統中的取舍和思考。對于復雜業務場景下的領域驅動設計具有借鑒意義。

一、案例介紹

攜程用車訂單相關業務包括接送機、包車、打車這些產線，訂單相關的功能包括訂單狀態管理、支付狀態管理、供應商訂單狀態管理、履約狀態管理，其中履約狀態中包含司機相關狀態，完成訂單需要將額外費用結清。

攜程租車訂單相關功能包括訂單狀態管理、支付狀態管理、押金扣款記錄、供應商訂單狀態管理、履約狀態管理，其中履約狀態主要是取車和還車相關狀態。

訂單和相關實體如下圖所示：

二、問題分析

由于兩車業務存在一些差異，為了讀者更容易理解，因此將抽取共性問題來說明。

2.1 溝通困難

關于溝通困難，我們發現整個開發過程中，溝通實際上是一個非常消耗時間的事情，需求方需要和產品溝通，產品要和研發人員溝通，研發開發過程中發現一些忽略的細節需要產品確認，來回之間耗費了大量時間。如果是跨團隊溝通，這樣的問題會更加復雜，以下總結了一些常見的場景：

• 產品不關心研發的實現，但是覺得需求很簡單或者很復雜。
• 研發開發過程中發現一些忽略的細節需要產品確認，產品要找需求方確認。
• 歷史邏輯沒人知道，需求評審的時候無法發現問題，做到最后發現有問題。
• 跨團隊之間不了解對方的業務，需要反復溝通確認。
• 遇到同一個名詞不同的理解導致無效溝通。
• 一個需求到底該哪個域來實現是我們在實踐中經常反復探討的問題。
• ...

例如訂單和供應商訂單在不同的團隊內都叫訂單，在溝通中針對“訂單”的討論就會產生歧義。

2.2 業務邊界不清晰

設計之初，訂單被各調用方當作了對外輸出的數據源頭，數據需求方只要調訂單詳情即可獲取全量數據，這為以后訂單的迭代帶來了相當大的隱患。訂單在自己的業務模型中加入大量不涉及自身業務的冗余字段，在系統的演進過程中，由于無腦插入他方業務字段使得訂單自己也要維護相關的邏輯（解釋和修改），導致各方對訂單的耦合日益加深，導致訂單服務的發布變成高風險行為，甚至一個無關訂單業務的相關字段修改也可能導致系統故障。

例如訂單上關于供應商的相關數據，用戶訂單有一份，采購訂單也有一份，當采購要修改供應商的相關邏輯時要用戶訂單也一起修改，而用戶訂單必須排查和推動相關使用到這個字段的業務方切換替代方案。

2.3 面對業務變化修改困難

隨著歷史業務迭代，訂單中耦合了許多非訂單關注的業務邏輯。例如歷史上給用戶發消息通知是根據用戶訂單狀態變化觸發的，由于和通知平臺交互，因此訂單要提供通知相關的所有參數，等于訂單依賴通知相關的模版，明顯存在核心依賴非核心的問題。而此時如果我們提出需求，要對于某些通知平臺發送失敗的消息進行重發，邏輯似乎也只能做到訂單上，不論怎么看都很不優雅。

三、解決方案

3.1 回歸業務本質——挖掘愿景

為了解決業務歸屬問題和明確系統發展方向，避免將資源投入那些非核心的功能，我們需要明確當前項目它是什么，目標是什么。因此我們需要為系統準備一份愿景，它將指導我們在未來的迭代中不迷失方向。這個愿景相當于我們的產品定位，是我們的系統和其它系統不同之處，也是當前系統的邊界。

愿景就像手電筒中發出的光，在光暗之間是我們系統的邊界，系統的未來也在光的方向中。

輸出一個愿景說明有很多方式，為了簡化落地的門檻，我們采取麥肯錫“電梯演講”的方式，圍繞機會、挑戰、優勢、劣勢給出一組結果，由領域專家和開發團隊一起進行頭腦風暴，實際上這也是DDD統一語言的開始，我們必須從愿景開始就達成一致。

友情提醒

Eric Even在他的書中曾提到過一種模式：領域愿景描述（Domain Vision Statement）

“由于一開始項目的模型通常不存在，但是需求是早已定下的重點，為了我們在后續階段清楚了解系統的價值，以價值作為我們的導向。”

我們在研究領域愿景描述時發現要寫出一份合格的文檔并不容易，因為它缺乏明確的規范和套路，Eric也只是給了我們幾個案例體會，不得不說雖然寫出來容易，但是要做到合格還是有門檻的。因此我們退一步，回到Eric說的愿景說明來：“很多項目團隊都會編寫‘愿景說明’以便管理。最好的愿景說明會展示出應用程序為組織帶來的具體價值。”

3.2 高效溝通——利用事件風暴統一語言

說到統一語言，最經典的例子應該是傳話游戲，一句話從最初的人口中說出，經歷中間多人轉述，最后可能完全變成另一種意思。

為了快速實現統一語言，我們在訂單重構中花了比較多的時間進行事件風暴。事件風暴有以下幾點優勢：

• 事件風暴圍繞業務流程進行討論，使在場的每一個人都通過多條流程深入了解業務實體的變化。
• 事件風暴聚集了“領域專家”，產品、開發、測試等，本質也是一場集合集體智慧的頭腦風暴，所有人在事件風暴中達成業務共識。
• 事件風暴集合了所有人的領域知識，同樣是一場領域知識的分享會。

原本事件風暴是以工作坊的方式在線下組織，這樣大家的參與感更強烈。但是由于成本和線上辦公的興起，我們在在線工作坊的實踐會更多一些。這里推薦兩個工具，一個是行知蜂（BeeArt），另一個是可畫（canva），都支持多人在線協作。

事件風暴其實非常簡單，就是業務流程+業務用例，將業務流程橫向展開，通過用例將業務中的名詞狀態變化一一列舉。其中色塊的大小和顏色可以參考www.eventstorming.com，但是我認為只要能夠統一大家的認知，顏色是次要的。

經過我們的嘗試，先列舉業務中單據的狀態變化，后補全觸發狀態變化的動作和角色效率會更高一些。關鍵是將大家認知中的不同事物相同名詞、不同名詞相同事物識別出來，利于后續建模。

通過事件風暴，我們主要關注以下幾種情況：

• 溝通中那些脫離當前領域就難以理解的詞匯；
• 相同名詞，含義不同的；
• 名詞不同，含義相同的。

將以上三種情況涉及的名詞動詞總結成統一語言表，特別是第三種情況恰恰是我們劃分限界上下文的關鍵依據。例如我們在聊支付單時發現存在兩種支付單，一個是包含我們業務的支付單，它需要記錄當前支付的場景并包含一定的業務規則；另一個是支付平臺的支付單，每次支付都會生成一個支付單，它可以認為是和更抽象的訂單相關（例如會員訂單、優惠券訂單）。

于是我們提取了費項記錄這個概念，表達一筆訂單可以有多個費項記錄，用于區分我們的支付

單和支付中臺的支付單之間的差別。

3.3 自上而下細化邊界——子域劃分

傳統面向過程的開發方法面對復雜系統通常會采用DFD數據流圖的方式進行拆分，在DDD中則是提出了子域的概念。我們總是會聽到領域（Domain）和子域（Sub Domain），不論是Eric的DDD還是IDDD中都大量使用這些概念，但是我們會發現他們并未向我們解釋清楚子域是如何劃分而來的。

對于一個已有的系統而言，我們可以根據康威定律得出：團隊邊界=系統邊界，因此可以認為每個團隊負責的部分就是天然的子域。由于目前訂單團隊本就分為用戶訂單組和采購派發組，因此我們可以初步得出一個領域劃分：

此時我們根據愿景，可以明確兩個子域各自的職責：用戶訂單子域負責提供用戶訂單流程的查看和管理，并且負責在需要的環節主動通知用戶；采購訂單子域則負責真正定后履約流程的流轉，包括供應商和行前行中行后的狀態更新。

最后支付使用的是攜程金融的能力，由于支付平臺的能力在攜程內部是統一的，因此我們認為支付平臺屬于通用域。

3.4 自下而上抽象概念——限界上下文

領域的概念相對而言還是模糊的，因此Eric提出了DDD中最重要的概念：限界上下文。而限界上下文并非憑空而來，而是需要對我們在事件風暴中得到的名詞進行歸納而來。

首先我們列舉了用戶訂單域的各種用例，包括下用戶單、支付訂單、修改訂單、取消訂單等。

通過建模法歸納模型，例如在訂單流程中我們存在多場景的支付，同時又依賴支付平臺的支付單，因此我們得到了維護支付單狀態的支付費項記錄，它既維護了支付單相關的信息，也維護了當前訂單系統內關于支付的業務邏輯。

最后我們根據業務相關性對得出的實體進行歸納，結合我們的愿景得出三個上下文，分別是：

• 用戶訂單狀態上下文：負責管理用戶訂單狀態管理；
• 支付費項上下文：負責訂單支付相關狀態管理；
• 用戶通知上下文：負責對用戶進行多種方式的通知。

3.5 挖掘業務變化的瓶頸——上下文依賴關系

實際上限界上下文可以拆到很細的粒度，但是我們應該遵循“奧康姆剃刀”的規則，盡量設置合理的數量，拆分的要有理有據。我們可以先看看原來的系統上下文依賴關系：

根據Eric對上下文關系的總結，我們可以得出消息中心作為攜程的消息中臺，不會為了某個業務線做特殊邏輯，因此是很明顯的遵奉者（Conformist）。此時消息相關的處理耦合在訂單內部，如果發送消息沒有業務邏輯那么采取防腐層（ACL）的方式是比較常見的。

由于我們已經識別到用戶通知存在業務邏輯，因此訂單直接和消息中心交互顯得奇怪，而且訂單作為核心域，本來就應該盡量不依賴其它域，對此我們進行了如下設計：

這樣用戶訂單上下文更加內聚，而用戶通知也更加易于迭代。

四、收益總結

4.1 業務邏輯耦合降低

通過上下文拆分和職責的明確，由各領域維護自己的數據和領域知識，使得訂單不再維護這些字段，而由數據寫入的業務方去維護，后續有和訂單無關的業務邏輯變更時訂單無需改動。

4.2 團隊效率提高

隨著上下文拆分和康威定律的應用，各團隊職責和各自的領域形成映射，過去由于團隊職責劃分不清，經常為某功能誰做來爭論不休的問題也得到了解決。

4.3 性能和穩定性提高

通過上下文拆分后，訂單實體從之前的780多個字段簡化到200多個字段，大大降低了訂單的維護成本，存儲數據量減少，原來的業務邏輯也由每個寫入方自己進行維護，接口性能p95 寫由68ms優化到12ms ，讀從63ms降低到5ms。

4.4 數據一致性

由于過去業務方寫入數據到訂單可能由于網絡抖動等原因寫入失敗或業務方寫錯數據導致修復數據需要兩邊一起改，現在業務方將數據存放在自己的領域內，不再存入訂單，避免了數據不一致和字段寫錯等問題的產生。

4.5 人力成本大幅下降

產研溝通涉及的相關方大量減少，鏈路縮短。刨去原本因為業務邏輯耦合導致訂單跟著修改的人力成本，整體人力成本小項目下降70%，大項目更是下降80%。

五、遇到的問題和方案探索

落地DDD實際上是一個非常困難的過程，我們必須面對缺乏領域專家，業務需求多且急，團隊對DDD理解不深等諸多問題。對此我們總結出以下幾點經驗：

5.1 領域專家難尋

領域專家是DDD中最重要的角色之一，沒有領域專家我們就無法獲取知識，就沒有后續的建模等等。但是實際工作中要尋找一個嚴格意義上的領域專家是困難且成本高昂的，因此我們需要尋求一些其它方式曲線救國，例如該領域的資深研發，資深QA等，同時我們兩車還采取互相借鑒的方式，雖然業務不完全相同，但是領域上也有互通之處。

5.2 業務需求多且急

實際工作中我們經常忙于各種業務項目，關鍵是還很急。這就很容易導致我們沒辦法專注于DDD改造，怎么辦呢？我們的方案是在有時間的時候把方向定下來，提前進行設計，然后在做業務項目時將這些設計逐步進行實現。

5.3 團隊對DDD理解不深

為了提高團隊對DDD的理解，我們專門成立了DDD培訓小組，將我們的一些落地經驗整理成規范和最佳實踐。同時在落地時由培訓小組的同學進行把關，避免大家走彎路。

以上就是此次分享的全部內容，如果后續大家有什么疑問可以在下方留言，如果后續有機會我們會在疑惑較多的點進行再次分享。希望大家通過這篇文章得到一些想要的收獲！