點選上方藍字訂閱，不錯過下一篇好文章

本文轉自美團點評技術公眾號：meituantech

前言

至少30年以前，一些軟體設計人員就已經意識到領域建模和設計的重要性，並形成一種思潮，Eric Evans將其定義為領域驅動設計（Domain-Driven Design，簡稱DDD）。在網際網路開發“小步快跑，迭代試錯”的大環境下，DDD似乎是一種比較“古老而緩慢”的思想。

然而，由於網際網路公司也逐漸深入實體經濟，業務日益複雜，我們在開發中也越來越多地遇到傳統行業軟體開發中所面臨的問題。本文就先來講一下這些問題，然後再嘗試在實踐中用DDD的思想來解決這些問題。

問題

過度耦合

業務初期，我們的功能大都非常簡單，普通的CRUD就能滿足，此時系統是清晰的。隨著迭代的不斷演化，業務邏輯變得越來越複雜，我們的系統也越來越冗雜。模組彼此關聯，誰都很難說清模組的具體功能意圖是啥。修改一個功能時，往往光回溯該功能需要的修改點就需要很長時間，更別提修改帶來的不可預知的影響面。

下圖是一個常見的系統耦合病例。

訂單服務介面中提供了查詢、建立訂單相關的介面，也提供了訂單評價、支付、保險的介面。同時我們的表也是一個訂單大表，包含了非常多欄位。在我們維護程式碼時，牽一髮而動全身，很可能只是想改下評價相關的功能，卻影響到了創單核心路徑。雖然我們可以通過測試保證功能完備性，但當我們在訂單領域有大量需求同時並行開發時，改動重疊、惡性迴圈、疲於奔命修改各種問題。

上述問題，歸根到底在於系統架構不清晰，劃分出來的模組內聚度低、高耦合。

有一種解決方案，按照演進式設計的理論，讓系統的設計隨著系統實現的增長而增長。我們不需要作提前設計，就讓系統伴隨業務成長而演進。這當然是可行的，敏捷實踐中的重構、測試驅動設計及持續整合可以對付各種混亂問題。重構——保持行為不變的程式碼改善清除了不協調的區域性設計，測試驅動設計確保對系統的更改不會導致系統丟失或破壞現有功能，持續整合則為團隊提供了同一程式碼庫。

在這三種實踐中，重構是克服演進式設計中大雜燴問題的主力，通過在單獨的類及方法級別上做一系列小步重構來完成。我們可以很容易重構出一個獨立的類來放某些通用的邏輯，但是你會發現你很難給它一個業務上的含義，只能給予一個技術維度描繪的含義。這會帶來什麼問題呢？新同學並不總是知道對通用邏輯的改動或獲取來自該類。顯然，制定專案規範並不是好的idea。我們又聞到了程式碼即將腐敗的味道。

事實上，你可能意識到問題之所在。在解決現實問題時，我們會將問題對映到腦海中的概念模型，在模型中解決問題，再將解決方案轉換為實際的程式碼。上述問題在於我們解決了設計到程式碼之間的重構，但提煉出來的設計模型，並不具有實際的業務含義，這就導致在開發新需求時，其他同學並不能很自然地將業務問題對映到該設計模型。設計似乎變成了重構者的自娛自樂，程式碼繼續腐敗，重新重構……無休止的迴圈。

用DDD則可以很好地解決領域模型到設計模型的同步、演化，最後再將反映了領域的設計模型轉為實際的程式碼。

注：模型是我們解決實際問題所抽象出來的概念模型，領域模型則表達與業務相關的事實；設計模型則描述了所要構建的系統。

貧血症和失憶症

貧血領域物件

貧血領域物件（Anemic Domain Object）是指僅用作資料載體，而沒有行為和動作的領域物件。

在我們習慣了J2EE的開發模式後，Action/Service/DAO這種分層模式，會很自然地寫出過程式程式碼，而學到的很多關於OO理論的也毫無用武之地。使用這種開發方式，物件只是資料的載體，沒有行為。以資料為中心，以資料庫ER設計作驅動。分層架構在這種開發模式下，可以理解為是對資料移動、處理和實現的過程。

以筆者最近開發的系統抽獎平臺為例：

• 場景需求

  獎池裡配置了很多獎項，我們需要按運營預先配置的概率抽中一個獎項。
  實現非常簡單，生成一個隨機數，匹配符合該隨機數生成概率的獎項即可。

• 貧血模型實現方案

  先設計獎池和獎項的庫表配置。

• 設計AwardPool和Award兩個物件，只有簡單的get和set屬性的方法

class AwardPool {    int awardPoolId;    List<Award> awards;    
  public List<Award> getAwards() {        
    return awards;    
  }    
  public void setAwards(List<Award> awards) {
        this.awards = awards;
            }    
  ......}
  class Award {   int awardId;   int probability;//概率   
  ......}

• Service程式碼實現

設計一個LotteryService，在其中的drawLottery()方法寫服務邏輯

AwardPool awardPool = awardPoolDao.getAwardPool(poolId);//sql查詢，將資料對映到AwardPool物件
for (Award award : awardPool.getAwards()) {  
//尋找到符合award.getProbability()概率的award
}

• 按照我們通常思路實現，可以發現：在業務領域裡非常重要的抽獎，我的業務邏輯都是寫在Service中的，Award充其量只是個數據載體，沒有任何行為。簡單的業務系統採用這種貧血模型和過程化設計是沒有問題的，但在業務邏輯複雜了，業務邏輯、狀態會散落到在大量方法中，原本的程式碼意圖會漸漸不明確，我們將這種情況稱為由貧血症引起的失憶症。

更好的是採用領域模型的開發方式，將資料和行為封裝在一起，並與現實世界中的業務物件相對映。各類具備明確的職責劃分，將領域邏輯分散到領域物件中。繼續舉我們上述抽獎的例子，使用概率選擇對應的獎品就應當放到AwardPool類中。

為什麼選擇DDD

軟體系統複雜性應對

解決複雜和大規模軟體的武器可以被粗略地歸為三類：抽象、分治和知識。

分治 把問題空間分割為規模更小且易於處理的若干子問題。分割後的問題需要足夠小，以便一個人單槍匹馬就能夠解決他們；其次，必須考慮如何將分割後的各個部分裝配為整體。分割得越合理越易於理解，在裝配成整體時，所需跟蹤的細節也就越少。即更容易設計各部分的協作方式。評判什麼是分治得好，即高內聚低耦合。

抽象 使用抽象能夠精簡問題空間，而且問題越小越容易理解。舉個例子，從北京到上海出差，可以先理解為使用交通工具前往，但不需要一開始就想清楚到底是高鐵還是飛機，以及乘坐他們需要注意什麼。

知識 顧名思義，DDD可以認為是知識的一種。

DDD提供了這樣的知識手段，讓我們知道如何抽象出限界上下文以及如何去分治。

與微服務架構相得益彰

微服務架構眾所周知，此處不做贅述。我們建立微服務時，需要建立一個高內聚、低耦合的微服務。而DDD中的限界上下文則完美匹配微服務要求，可以將該限界上下文理解為一個微服務程序。

上述是從更直觀的角度來描述兩者的相似處。

在系統複雜之後，我們都需要用分治來拆解問題。一般有兩種方式，技術維度和業務維度。技術維度是類似MVC這樣，業務維度則是指按業務領域來劃分系統。

微服務架構更強調從業務維度去做分治來應對系統複雜度，而DDD也是同樣的著重業務視角。

如果兩者在追求的目標（業務維度）達到了上下文的統一，那麼在具體做法上有什麼聯絡和不同呢？

我們將架構設計活動精簡為以下三個層面：

• 業務架構——根據業務需求設計業務模組及其關係

• 系統架構——設計系統和子系統的模組

• 技術架構——決定採用的技術及框架

以上三種活動在實際開發中是有先後順序的，但不一定孰先孰後。在我們解決常規套路問題時，我們會很自然地往熟悉的分層架構套（先確定系統架構），或者用PHP開發很快（先確定技術架構），在業務不復雜時，這樣是合理的。

跳過業務架構設計出來的架構關注點不在業務響應上，可能就是個大泥球，在面臨需求迭代或響應市場變化時就很痛苦。

DDD的核心訴求就是將業務架構對映到系統架構上，在響應業務變化調整業務架構時，也隨之變化系統架構。而微服務追求業務層面的複用，設計出來的系統架構和業務一致；在技術架構上則系統模組之間充分解耦，可以自由地選擇合適的技術架構，去中心化地治理技術和資料。

可以參見下圖來更好地理解雙方之間的協作關係：

如何實踐DDD

我們將通過上文提到的抽獎平臺，來詳細介紹我們如何通過DDD來解構一箇中型的基於微服務架構的系統，從而做到系統的高內聚、低耦合。

首先看下抽獎系統的大致需求：

運營——可以配置一個抽獎活動，該活動面向一個特定的使用者群體，並針對一個使用者群體發放一批不同型別的獎品（優惠券，啟用碼，實物獎品等）。

使用者-通過活動頁面參與不同型別的抽獎活動。

設計領域模型的一般步驟如下：

1. 根據需求劃分出初步的領域和限界上下文，以及上下文之間的關係；

2. 進一步分析每個上下文內部，識別出哪些是實體，哪些是值物件；

3. 對實體、值物件進行關聯和聚合，劃分出聚合的範疇和聚合根；

4. 為聚合根設計倉儲，並思考實體或值物件的建立方式；

5. 在工程中實踐領域模型，並在實踐中檢驗模型的合理性，倒推模型中不足的地方並重構。

戰略建模

戰略和戰術設計是站在DDD的角度進行劃分。戰略設計側重於高層次、巨集觀上去劃分和整合限界上下文，而戰術設計則關注更具體使用建模工具來細化上下文。

領域

現實世界中，領域包含了問題域和解系統。一般認為軟體是對現實世界的部分模擬。在DDD中，解系統可以對映為一個個限界上下文，限界上下文就是軟體對於問題域的一個特定的、有限的解決方案。

限界上下文

限界上下文

一個由顯示邊界限定的特定職責。領域模型便存在於這個邊界之內。在邊界內，每一個模型概念，包括它的屬性和操作，都具有特殊的含義。

一個給定的業務領域會包含多個限界上下文，想與一個限界上下文溝通，則需要通過顯示邊界進行通訊。系統通過確定的限界上下文來進行解耦，而每一個上下文內部緊密組織，職責明確，具有較高的內聚性。

一個很形象的隱喻：細胞質所以能夠存在，是因為細胞膜限定了什麼在細胞內，什麼在細胞外，並且確定了什麼物質可以通過細胞膜。

劃分限界上下文

劃分限界上下文，不管是Eric Evans還是Vaughn Vernon，在他們的大作裡都沒有怎麼提及。

顯然我們不應該按技術架構或者開發任務來建立限界上下文，應該按照語義的邊界來考慮。

我們的實踐是，考慮產品所講的通用語言，從中提取一些術語稱之為概念物件，尋找物件之間的聯絡；或者從需求裡提取一些動詞，觀察動詞和物件之間的關係；我們將緊耦合的各自圈在一起，觀察他們內在的聯絡，從而形成對應的界限上下文。形成之後，我們可以嘗試用語言來描述下界限上下文的職責，看它是否清晰、準確、簡潔和完整。簡言之，限界上下文應該從需求出發，按領域劃分。

前文提到，我們的使用者劃分為運營和使用者。其中，運營對抽獎活動的配置十分複雜但相對低頻。使用者對這些抽獎活動配置的使用是高頻次且無感知的。根據這樣的業務特點，我們首先將抽獎平臺劃分為C端抽獎和M端抽獎管理平臺兩個子域，讓兩者完全解耦。

在確認了M端領域和C端的限界上下文後，我們再對各自上下文內部進行限界上下文的劃分。下面我們用C端進行舉例。

產品的需求概述如下：

1. 抽獎活動有活動限制，例如使用者的抽獎次數限制，抽獎的開始和結束的時間等；
2. 一個抽獎活動包含多個獎品，可以針對一個或多個使用者群體；
3. 獎品有自身的獎品配置，例如庫存量，被抽中的概率等，最多被一個使用者抽中的次數等等；
4. 使用者群體有多種區別方式，如按照使用者所在城市區分，按照新老客區分等；
5. 活動具有風控配置，能夠限制使用者參與抽獎的頻率。

根據產品的需求，我們提取了一些關鍵性的概念作為子域，形成我們的限界上下文。

首先，抽獎上下文作為整個領域的核心，承擔著使用者抽獎的核心業務，抽獎中包含了獎品和使用者群體的概念。

• 在設計初期，我們曾經考慮劃分出抽獎和發獎兩個領域，前者負責選獎，後者負責將選中的獎品發放出去。但在實際開發過程中，我們發現這兩部分的邏輯緊密連線，難以拆分。並且單純的發獎邏輯足夠簡單，僅僅是呼叫第三方服務進行發獎，不足以獨立出來成為一個領域。

對於活動的限制，我們定義了活動准入的通用語言，將活動開始/結束時間，活動可參與次數等限制條件都收攏到活動准入上下文中。

對於抽獎的獎品庫存量，由於庫存的行為與獎品本身相對解耦，庫存關注點更多是庫存內容的核銷，且庫存本身具備通用性，可以被獎品之外的內容使用，因此我們定義了獨立的庫存上下文。

由於C端存在一些刷單行為，我們根據產品需求定義了風控上下文，用於對活動進行風控。

最後，活動准入、風控、抽獎等領域都涉及到一些次數的限制，因此我們定義了計數上下文。

可以看到，通過DDD的限界上下文劃分，我們界定出抽獎、活動准入、風控、計數、庫存等五個上下文，每個上下文在系統中都高度內聚。

上下文對映圖

在進行上下文劃分之後，我們還需要進一步梳理上下文之間的關係。

康威（梅爾·康威）定律

任何組織在設計一套系統（廣義概念上的系統）時，所交付的設計方案在結構上都與該組織的溝通結構保持一致。

康威定律告訴我們，系統結構應儘量的與組織結構保持一致。這裡，我們認為團隊結構（無論是內部組織還是團隊間組織）就是組織結構，限界上下文就是系統的業務結構。因此，團隊結構應該和限界上下文保持一致。

梳理清楚上下文之間的關係，從團隊內部的關係來看，有如下好處：

1. 任務更好拆分，一個開發人員可以全身心的投入到相關的一個單獨的上下文中；

2. 溝通更加順暢，一個上下文可以明確自己對其他上下文的依賴關係，從而使得團隊內開發直接更好的對接。

從團隊間的關係來看，明確的上下文關係能夠帶來如下幫助：

1. 每個團隊在它的上下文中能夠更加明確自己領域內的概念，因為上下文是領域的解系統；

2. 對於限界上下文之間發生互動，團隊與上下文的一致性，能夠保證我們明確對接的團隊和依賴的上下游。

限界上下文之間的對映關係

• 合作關係（Partnership）：兩個上下文緊密合作的關係，一榮俱榮，一損俱損。

• 共享核心（Shared Kernel）：兩個上下文依賴部分共享的模型。

• 客戶方-供應方開發（Customer-Supplier Development）：上下文之間有組織的上下游依賴。

• 遵奉者（Conformist）：下游上下文只能盲目依賴上游上下文。

• 防腐層（Anticorruption Layer）：一個上下文通過一些適配和轉換與另一個上下文互動。

• 開放主機服務（Open Host Service）：定義一種協議來讓其他上下文來對本上下文進行訪問。

• 釋出語言（Published Language）：通常與OHS一起使用，用於定義開放主機的協議。

• 大泥球（Big Ball of Mud）：混雜在一起的上下文關係，邊界不清晰。

• 另謀他路（SeparateWay）：兩個完全沒有任何聯絡的上下文。

上文定義了上下文對映間的關係，經過我們的反覆斟酌，抽獎平臺上下文的對映關係圖如下：

由於抽獎，風控，活動准入，庫存，計數五個上下文都處在抽獎領域的內部，所以它們之間符合“一榮俱榮，一損俱損”的合作關係（PartnerShip，簡稱PS）。

同時，抽獎上下文在進行發券動作時，會依賴券碼、平臺券、外賣券三個上下文。抽獎上下文通過防腐層（Anticorruption Layer，ACL）對三個上下文進行了隔離，而三個券上下文通過開放主機服務（Open Host Service）作為釋出語言（Published Language）對抽獎上下文提供訪問機制。

通過上下文對映關係，我們明確的限制了限界上下文的耦合性，即在抽獎平臺中，無論是上下文內部互動（合作關係）還是與外部上下文互動（防腐層），耦合度都限定在資料耦合（Data Coupling）的層級。

戰術建模——細化上下文

梳理清楚上下文之間的關係後，我們需要從戰術層面上剖析上下文內部的組織關係。首先看下DDD中的一些定義。

實體

當一個物件由其標識（而不是屬性）區分時，這種物件稱為實體（Entity）。

例：最簡單的，公安系統的身份資訊錄入，對於人的模擬，即認為是實體，因為每個人是獨一無二的，且其具有唯一標識（如公安系統分發的身份證號碼）。

在實踐上建議將屬性的驗證放到實體中。

值物件

當一個物件用於對事務進行描述而沒有唯一標識時，它被稱作值物件（Value Object）。

例：比如顏色資訊，我們只需要知道{"name":"黑色"，"css":"#000000"}這樣的值資訊就能夠滿足要求了，這避免了我們對標識追蹤帶來的系統複雜性。

值物件很重要，在習慣了使用資料庫的資料建模後，很容易將所有物件看作實體。使用值物件，可以更好地做系統優化、精簡設計。

它具有不變性、相等性和可替換性。

在實踐中，需要保證值物件建立後就不能被修改，即不允許外部再修改其屬性。在不同上下文整合時，會出現模型概念的公用，如商品模型會存在於電商的各個上下文中。在訂單上下文中如果你只關注下單時商品資訊快照，那麼將商品物件視為值物件是很好的選擇。

聚合根

Aggregate(聚合）是一組相關物件的集合，作為一個整體被外界訪問，聚合根（Aggregate Root）是這個聚合的根節點。

聚合是一個非常重要的概念，核心領域往往都需要用聚合來表達。其次，聚合在技術上有非常高的價值，可以指導詳細設計。

聚合由根實體，值物件和實體組成。

如何建立好的聚合？

• 邊界內的內容具有一致性：在一個事務中只修改一個聚合例項。如果你發現邊界內很難接受強一致，不管是出於效能或產品需求的考慮，應該考慮剝離出獨立的聚合，採用最終一致的方式。

• 設計小聚合：大部分的聚合都可以只包含根實體，而無需包含其他實體。即使一定要包含，可以考慮將其建立為值物件。

• 通過唯一標識來引用其他聚合或實體：當存在物件之間的關聯時，建議引用其唯一標識而非引用其整體物件。如果是外部上下文中的實體，引用其唯一標識或將需要的屬性構造值物件。
  如果聚合建立複雜，推薦使用工廠方法來遮蔽內部複雜的建立邏輯。

聚合內部多個組成物件的關係可以用來指導資料庫建立，但不可避免存在一定的抗阻。如聚合中存在List<值物件>，那麼在資料庫中建立1:N的關聯需要將值物件單獨建表，此時是有ID的，建議不要將該ID暴露到資源庫外部，對外隱蔽。

領域服務

一些重要的領域行為或操作，可以歸類為領域服務。它既不是實體，也不是值物件的範疇。

當我們採用了微服務架構風格，一切領域邏輯的對外暴露均需要通過領域服務來進行。如原本由聚合根暴露的業務邏輯也需要依託於領域服務。

領域事件

領域事件是對領域內發生的活動進行的建模。

抽獎平臺的核心上下文是抽獎上下文，接下來介紹下我們對抽獎上下文的建模。

在抽獎上下文中，我們通過抽獎(DrawLottery)這個聚合根來控制抽獎行為，可以看到，一個抽獎包括了抽獎ID（LotteryId）以及多個獎池（AwardPool），而一個獎池針對一個特定的使用者群體（UserGroup）設定了多個獎品（Award）。

另外，在抽獎領域中，我們還會使用抽獎結果（SendResult）作為輸出資訊，使用使用者領獎記錄（UserLotteryLog）作為領獎憑據和存根。

謹慎使用值物件

在實踐中，我們發現雖然一些領域物件符合值物件的概念，但是隨著業務的變動，很多原有的定義會發生變更，值物件可能需要在業務意義具有唯一標識，而對這類值物件的重構往往需要較高成本。因此在特定的情況下，我們也要根據實際情況來權衡領域物件的選型。

DDD工程實現

在對上下文進行細化後，我們開始在工程中真正落地DDD。

模組

模組（Module）是DDD中明確提到的一種控制限界上下文的手段，在我們的工程中，一般儘量用一個模組來表示一個領域的限界上下文。

如程式碼中所示，一般的工程中包的組織方式為{com.公司名.組織架構.業務.上下文.*}，這樣的組織結構能夠明確的將一個上下文限定在包的內部。

對於模組內的組織結構，一般情況下我們是按照領域物件、領域服務、領域資源庫、防腐層等組織方式定義的。

每個模組的具體實現，我們將在下文中展開。

領域物件

前文提到，領域驅動要解決的一個重要的問題，就是解決物件的貧血問題。這裡我們用之前定義的抽獎（DrawLottery）聚合根和獎池（AwardPool）值物件來具體說明。

抽獎聚合根持有了抽獎活動的id和該活動下的所有可用獎池列表，它的一個最主要的領域功能就是根據一個抽獎發生場景（DrawLotteryContext），選擇出一個適配的獎池，即chooseAwardPool方法。

chooseAwardPool的邏輯是這樣的：DrawLotteryContext會帶有使用者抽獎時的場景資訊（抽獎得分或抽獎時所在的城市），DrawLottery會根據這個場景資訊，匹配一個可以給使用者發獎的AwardPool。

在匹配到一個具體的獎池之後，需要確定最後給使用者的獎品是什麼。

這部分的領域功能在AwardPool內。

與以往的僅有getter、setter的業務物件不同，領域物件具有了行為，物件更加豐滿。同時，比起將這些邏輯寫在服務內（例如**Service），領域功能的內聚性更強，職責更加明確。

資源庫

領域物件需要資源儲存，儲存的手段可以是多樣化的，常見的無非是資料庫，分散式快取，本地快取等。資源庫（Repository）的作用，就是對領域的儲存和訪問進行統一管理的物件。在抽獎平臺中，我們是通過如下的方式組織資源庫的。

資源庫對外的整體訪問由Repository提供，它聚合了各個資源庫的資料資訊，同時也承擔了資源儲存的邏輯（例如快取更新機制等）。

在抽獎資源庫中，我們遮蔽了對底層獎池和獎品的直接訪問，而是僅對抽獎的聚合根進行資源管理。程式碼示例中展示了抽獎資源獲取的方法（最常見的Cache Aside Pattern）。

比起以往將資源管理放在服務中的做法，由資源庫對資源進行管理，職責更加明確，程式碼的可讀性和可維護性也更強。

程式碼演示6 DrawLotteryRepository

防腐層

亦稱適配層。在一個上下文中，有時需要對外部上下文進行訪問，通常會引入防腐層的概念來對外部上下文的訪問進行一次轉義。

有以下幾種情況會考慮引入防腐層：

• 需要將外部上下文中的模型翻譯成本上下文理解的模型。

• 不同上下文之間的團隊協作關係，如果是供奉者關係，建議引入防腐層，避免外部上下文變化對本上下文的侵蝕。

• 該訪問本上下文使用廣泛，為了避免改動影響範圍過大。

如果內部多個上下文對外部上下文需要訪問，那麼可以考慮將其放到通用上下文中。

在抽獎平臺中，我們定義了使用者城市資訊防腐層

(UserCityInfoFacade)，用於外部的使用者城市資訊上下文（微服務架構下表現為使用者城市資訊服務）。

以使用者資訊防腐層舉例，它以抽獎請求引數(LotteryContext)為入參，以城市資訊(MtCityInfo)為輸出。

領域服務

上文中，我們將領域行為封裝到領域物件中，將資源管理行為封裝到資源庫中，將外部上下文的互動行為封裝到防腐層中。此時，我們再回過頭來看領域服務時，能夠發現領域服務本身所承載的職責也就更加清晰了，即就是通過串聯領域物件、資源庫和防腐層等一系列領域內的物件的行為，對其他上下文提供互動的介面。

我們以抽獎服務為例（issueLottery），可以看到在省略了一些防禦性邏輯（異常處理，空值判斷等）後，領域服務的邏輯已經足夠清晰明瞭。

資料流轉

在抽獎平臺的實踐中，我們的資料流轉如上圖所示。

首先領域的開放服務通過資訊傳輸物件（DTO）來完成與外界的資料互動；在領域內部，我們通過領域物件（DO）作為領域內部的資料和行為載體；在資源庫內部，我們沿襲了原有的資料庫持久化物件（PO）進行資料庫資源的互動。同時，DTO與DO的轉換髮生在領域服務內，DO與PO的轉換髮生在資源庫內。

與以往的業務服務相比，當前的編碼規範可能多造成了一次資料轉換，但每種資料物件職責明確，資料流轉更加清晰。

上下文整合

通常整合上下文的手段有多種，常見的手段包括開放領域服務介面、開放HTTP服務以及訊息釋出-訂閱機制。

在抽獎系統中，我們使用的是開放服務介面進行互動的。最明顯的體現是計數上下文，它作為一個通用上下文，對抽獎、風控、活動准入等上下文都提供了訪問介面。

同時，如果在一個上下文對另一個上下文進行整合時，若需要一定的隔離和適配，可以引入防腐層的概念。這一部分的示例可以參考前文的防腐層程式碼示例。

分離領域

接下來講解在實施領域模型的過程中，如何應用到系統架構中。

我們採用的微服務架構風格，與Vernon在《實現領域驅動設計》並不太一致，更具體差異可閱讀他的書體會。

如果我們維護一個從前到後的應用系統：

下圖中領域服務是使用微服務技術剝離開來，獨立部署，對外暴露的只能是服務介面，領域對外暴露的業務邏輯只能依託於領域服務。而在Vernon著作中，並未假定微服務架構風格，因此領域層暴露的除了領域服務外，還有聚合、實體和值物件等。此時的應用服務層是比較簡單的，獲取來自介面層的請求引數，排程多個領域服務以實現介面層功能。

隨著業務發展，業務系統快速膨脹，我們的系統屬於核心時：

應用服務雖然沒有領域邏輯，但涉及到了對多個領域服務的編排。當業務規模龐大到一定程度，編排本身就富含了業務邏輯（除此之外，應用服務在穩定性、效能上所做的措施也希望統一起來，而非散落各處），那麼此時應用服務對於外部來說是一個領域服務，整體看起來則是一個獨立的限界上下文。

此時應用服務對內還屬於應用服務，對外已是領域服務的概念，需要將其暴露為微服務。

注：具體的架構實踐可按照團隊和業務的實際情況來，此處僅為作者自身的業務實踐。除分層架構外，如CQRS架構也是不錯的選擇

以下是一個示例。我們定義了抽獎、活動准入、風險控制等多個領域服務。在本系統中，我們需要整合多個領域服務，為客戶端提供一套功能完備的抽獎應用服務。這個應用服務的組織如下：

結語

在本文中，我們採用了分治的思想，從抽象到具體闡述了DDD在網際網路真實業務系統中的實踐。通過領域驅動設計這個強大的武器，我們將系統解構的更加合理。

但值得注意的是，如果你面臨的系統很簡單或者做一些SmartUI之類，那麼你不一定需要DDD。儘管本文對貧血模型、演進式設計提出了些許看法，但它們在特定範圍和具體場景下會更高效。讀者需要針對自己的實際情況，做一定取捨，適合自己的才是最好的。

本篇通過DDD來講述軟體設計的術與器，本質是為了高內聚低耦合，緊靠本質，按自己的理解和團隊情況來實踐DDD即可。

另外，關於DDD在迭代過程中模型腐化的相關問題，本文中沒有提及，將在後續的文章中論述，敬請期待。

鑑於作者經驗有限，我們對領域驅動的理解難免會有不足之處，歡迎大家共同探討，共同提高。

參考書籍

Eric Evans.領域驅動設計.趙俐 盛海豔 劉霞等譯.人民郵電出版社，2016.
Vaughn Vernon.實現領域驅動設計.滕雲 張逸譯.電子工業出版社，2014.

作者簡介

文彬、子維，美團點評資深研發工程師，畢業於南京大學，現從事美團外賣營銷相關的研發工作。

DDD

美團點評

技術團隊

http://tech.meituan.com

長按二維碼關注我們

更多技術部落格：美團點評技術部落格。

PS：正文中標綠的名詞均為參考連結，可點選查詢。

培訓報名

（以上圖片來自DDD領域建模峰會，版權歸組委會所有）

張逸老師即將在成都推出領域驅動設計公開課，兩天的課程，4個單元，從瞭解領域驅動設計、戰略式設計、戰術式設計到領域建模實戰演練，手把手教您進入領域驅動設計殿堂！僅餘最後5席，歡迎公司組團參加！！！

歡迎點選閱讀原文瞭解詳情