<b>前言</b>
至少30年以前，一些軟體設計人員就已經意識到領域模組化和設計的重要性，并形成一種思潮，Eric Evans将其定義為領域驅動設計（Domain-Driven Design，簡稱DDD）。在網際網路開發“小步快跑，疊代試錯”的大環境下，DDD似乎是一種比較“古老而緩慢”的思想。
然而，由于網際網路公司也逐漸深入實體經濟，業務日益複雜，我們在開發中也越來越多地遇到傳統行業軟體開發中所面臨的問題。本文就先來講一下這些問題，然後再嘗試在實踐中用DDD的思想來解決這些問題。
<b>問題</b>
業務初期，我們的功能大都非常簡單，普通的CRUD就能滿足，此時系統是清晰的。随着疊代的不斷演化，業務邏輯變得越來越複雜，我們的系統也越來越冗雜。子產品彼此關聯，誰都很難說清子產品的具體功能意圖是啥。修改一個功能時，往往光回溯該功能需要的修改點就需要很長時間，更别提修改帶來的不可預知的影響面。
下圖是一個常見的系統耦合病例。
訂單服務接口中提供了查詢、建立訂單相關的接口，也提供了訂單評價、支付、保險的接口。同時我們的表也是一個訂單大表，包含了非常多字段。在我們維護代碼時，牽一發而動全身，很可能隻是想改下評價相關的功能，卻影響到了創單核心路徑。雖然我們可以通過測試保證功能完備性，但當我們在訂單領域有大量需求同時并行開發時，改動重疊、惡性循環、疲于奔命修改各種問題。
上述問題，歸根到底在于系統架構不清晰，劃分出來的子產品内聚度低、高耦合。
有一種解決方案，按照演進式設計的理論，讓系統的設計随着系統實作的增長而增長。我們不需要作提前設計，就讓系統伴随業務成長而演進。這當然是可行的，靈活實踐中的重構、測試驅動設計及持續內建可以對付各種混亂問題。重構——保持行為不變的代碼改善清除了不協調的局部設計，測試驅動設計確定對系統的更改不會導緻系統丢失或破壞現有功能，持續內建則為團隊提供了同一代碼庫。
在這三種實踐中，重構是克服演進式設計中大雜燴問題的主力，通過在單獨的類及方法級别上做一系列小步重構來完成。我們可以很容易重構出一個獨立的類來放某些通用的邏輯，但是你會發現你很難給它一個業務上的含義，隻能給予一個技術次元描繪的含義。這會帶來什麼問題呢？新同學并不總是知道對通用邏輯的改動或擷取來自該類。顯然，制定項目規範并不是好的idea。我們又聞到了代碼即将腐敗的味道。
事實上，你可能意識到問題之所在。在解決現實問題時，我們會将問題映射到腦海中的概念模型，在模型中解決問題，再将解決方案轉換為實際的代碼。上述問題在于我們解決了設計到代碼之間的重構，但提煉出來的設計模型，并不具有實際的業務含義，這就導緻在開發新需求時，其他同學并不能很自然地将業務問題映射到該設計模型。設計似乎變成了重構者的自娛自樂，代碼繼續腐敗，重新重構……無休止的循環。
用DDD則可以很好地解決領域模型到設計模型的同步、演化，最後再将反映了領域的設計模型轉為實際的代碼。
注：模型是我們解決實際問題所抽象出來的概念模型，領域模型則表達與業務相關的事實；設計模型則描述了所要建構的系統。
貧血領域對象
貧血領域對象（Anemic Domain Object）是指僅用作資料載體，而沒有行為和動作的領域對象。
在我們習慣了J2EE的開發模式後，Action/Service/DAO這種分層模式，會很自然地寫出過程式代碼，而學到的很多關于OO理論的也毫無用武之地。使用這種開發方式，對象隻是資料的載體，沒有行為。以資料為中心，以資料庫ER設計作驅動。分層架構在這種開發模式下，可以了解為是對資料移動、處理和實作的過程。
以筆者最近開發的系統抽獎平台為例：
場景需求
獎池裡配置了很多獎項，我們需要按營運預先配置的機率抽中一個獎項。
實作非常簡單，生成一個随機數，比對符合該随機數生成機率的獎項即可。
貧血模型實作方案
先設計獎池和獎項的庫表配置。
設計AwardPool和Award兩個對象，隻有簡單的get和set屬性的方法
Service代碼實作
設計一個LotteryService，在其中的drawLottery()方法寫服務邏輯
按照我們通常思路實作，可以發現：在業務領域裡非常重要的抽獎，我的業務邏輯都是寫在Service中的，Award充其量隻是個資料載體，沒有任何行為。簡單的業務系統采用這種貧血模型和過程化設計是沒有問題的，但在業務邏輯複雜了，業務邏輯、狀态會散落到在大量方法中，原本的代碼意圖會漸漸不明确，我們将這種情況稱為由貧血症引起的失憶症。
更好的是采用領域模型的開發方式，将資料和行為封裝在一起，并與現實世界中的業務對象相映射。各類具備明确的職責劃分，将領域邏輯分散到領域對象中。繼續舉我們上述抽獎的例子，使用機率選擇對應的獎品就應當放到AwardPool類中。
<b>為什麼選擇DDD</b>
解決複雜和大規模軟體的武器可以被粗略地歸為三類：抽象、分治和知識。
分治 把問題空間分割為規模更小且易于處理的若幹子問題。分割後的問題需要足夠小，以便一個人單槍匹馬就能夠解決他們；其次，必須考慮如何将分割後的各個部分裝配為整體。分割得越合理越易于了解，在裝配成整體時，所需跟蹤的細節也就越少。即更容易設計各部分的協作方式。評判什麼是分治得好，即高内聚低耦合。
抽象 使用抽象能夠精簡問題空間，而且問題越小越容易了解。舉個例子，從北京到上海出差，可以先了解為使用交通工具前往，但不需要一開始就想清楚到底是高鐵還是飛機，以及乘坐他們需要注意什麼。
知識 顧名思義，DDD可以認為是知識的一種。
DDD提供了這樣的知識手段，讓我們知道如何抽象出限界上下文以及如何去分治。
微服務架構衆所周知，此處不做贅述。我們建立微服務時，需要建立一個高内聚、低耦合的微服務。而DDD中的限界上下文則完美比對微服務要求，可以将該限界上下文了解為一個微服務程序。
上述是從更直覺的角度來描述兩者的相似處。
在系統複雜之後，我們都需要用分治來拆解問題。一般有兩種方式，技術次元和業務次元。技術次元是類似MVC這樣，業務次元則是指按業務領域來劃分系統。
微服務架構更強調從業務次元去做分治來應對系統複雜度，而DDD也是同樣的着重業務視角。
如果兩者在追求的目标（業務次元）達到了上下文的統一，那麼在具體做法上有什麼聯系和不同呢？
我們将架構設計活動精簡為以下三個層面：
業務架構——根據業務需求設計業務子產品及其關系
系統架構——設計系統和子系統的子產品
技術架構——決定采用的技術及架構
以上三種活動在實際開發中是有先後順序的，但不一定孰先孰後。在我們解決正常套路問題時，我們會很自然地往熟悉的分層架構套（先确定系統架構），或者用PHP開發很快（先确定技術架構），在業務不複雜時，這樣是合理的。
跳過業務架構設計出來的架構關注點不在業務響應上，可能就是個大泥球，在面臨需求疊代或響應市場變化時就很痛苦。
DDD的核心訴求就是将業務架構映射到系統架構上，在響應業務變化調整業務架構時，也随之變化系統架構。而微服務追求業務層面的複用，設計出來的系統架構和業務一緻；在技術架構上則系統子產品之間充分解耦，可以自由地選擇合适的技術架構，去中心化地治理技術和資料。
可以參見下圖來更好地了解雙方之間的協作關系：
<b>如何實踐DDD</b>
我們将通過上文提到的抽獎平台，來詳細介紹我們如何通過DDD來解構一個中型的基于微服務架構的系統，進而做到系統的高内聚、低耦合。
首先看下抽獎系統的大緻需求：
營運——可以配置一個抽獎活動，該活動面向一個特定的使用者群體，并針對一個使用者群體發放一批不同類型的獎品（優惠券，激活碼，實物獎品等）。
使用者-通過活動頁面參與不同類型的抽獎活動。
設計領域模型的一般步驟如下：
根據需求劃分出初步的領域和限界上下文，以及上下文之間的關系；
進一步分析每個上下文内部，識别出哪些是實體，哪些是值對象；
對實體、值對象進行關聯和聚合，劃分出聚合的範疇和聚合根；
為聚合根設計倉儲，并思考實體或值對象的建立方式；
在工程中實踐領域模型，并在實踐中檢驗模型的合理性，倒推模型中不足的地方并重構。
戰略和戰術設計是站在DDD的角度進行劃分。戰略設計側重于高層次、宏觀上去劃分和內建限界上下文，而戰術設計則關注更具體使用模組化工具來細化上下文。
現實世界中，領域包含了問題域和解系統。一般認為軟體是對現實世界的部分模拟。在DDD中，解系統可以映射為一個個限界上下文，限界上下文就是軟體對于問題域的一個特定的、有限的解決方案。
限界上下文
一個由顯示邊界限定的特定職責。領域模型便存在于這個邊界之内。在邊界内，每一個模型概念，包括它的屬性和操作，都具有特殊的含義。
一個給定的業務領域會包含多個限界上下文，想與一個限界上下文溝通，則需要通過顯示邊界進行通信。系統通過确定的限界上下文來進行解耦，而每一個上下文内部緊密組織，職責明确，具有較高的内聚性。
一個很形象的隐喻：細胞質是以能夠存在，是因為細胞膜限定了什麼在細胞内，什麼在細胞外，并且确定了什麼物質可以通過細胞膜。
劃分限界上下文，不管是Eric Evans還是Vaughn Vernon，在他們的大作裡都沒有怎麼提及。
顯然我們不應該按技術架構或者開發任務來建立限界上下文，應該按照語義的邊界來考慮。
我們的實踐是，考慮産品所講的通用語言，從中提取一些術語稱之為概念對象，尋找對象之間的聯系；或者從需求裡提取一些動詞，觀察動詞和對象之間的關系；我們将緊耦合的各自圈在一起，觀察他們内在的聯系，進而形成對應的界限上下文。形成之後，我們可以嘗試用語言來描述下界限上下文的職責，看它是否清晰、準确、簡潔和完整。簡言之，限界上下文應該從需求出發，按領域劃分。
前文提到，我們的使用者劃分為營運和使用者。其中，營運對抽獎活動的配置十分複雜但相對低頻。使用者對這些抽獎活動配置的使用是高頻次且無感覺的。根據這樣的業務特點，我們首先将抽獎平台劃分為C端抽獎和M端抽獎管理平台兩個子域，讓兩者完全解耦。
在确認了M端領域和C端的限界上下文後，我們再對各自上下文内部進行限界上下文的劃分。下面我們用C端進行舉例。
産品的需求概述如下：
根據産品的需求，我們提取了一些關鍵性的概念作為子域，形成我們的限界上下文。
首先，抽獎上下文作為整個領域的核心，承擔着使用者抽獎的核心業務，抽獎中包含了獎品和使用者群體的概念。
在設計初期，我們曾經考慮劃分出抽獎和發獎兩個領域，前者負責選獎，後者負責将選中的獎品發放出去。但在實際開發過程中，我們發現這兩部分的邏輯緊密連接配接，難以拆分。并且單純的發獎邏輯足夠簡單，僅僅是調用第三方服務進行發獎，不足以獨立出來成為一個領域。
對于活動的限制，我們定義了活動準入的通用語言，将活動開始/結束時間，活動可參與次數等限制條件都收攏到活動準入上下文中。
對于抽獎的獎品庫存量，由于庫存的行為與獎品本身相對解耦，庫存關注點更多是庫存内容的核銷，且庫存本身具備通用性，可以被獎品之外的内容使用，是以我們定義了獨立的庫存上下文。
由于C端存在一些刷單行為，我們根據産品需求定義了風控上下文，用于對活動進行風控。
最後，活動準入、風控、抽獎等領域都涉及到一些次數的限制，是以我們定義了計數上下文。
可以看到，通過DDD的限界上下文劃分，我們界定出抽獎、活動準入、風控、計數、庫存等五個上下文，每個上下文在系統中都高度内聚。
在進行上下文劃分之後，我們還需要進一步梳理上下文之間的關系。
康威（梅爾·康威）定律
任何組織在設計一套系統（廣義概念上的系統）時，所傳遞的設計方案在結構上都與該組織的溝通結構保持一緻。
康威定律告訴我們，系統結構應盡量的與組織結構保持一緻。這裡，我們認為團隊結構（無論是内部組織還是團隊間組織）就是組織結構，限界上下文就是系統的業務結構。是以，團隊結構應該和限界上下文保持一緻。
梳理清楚上下文之間的關系，從團隊内部的關系來看，有如下好處：
任務更好拆分，一個開發人員可以全身心的投入到相關的一個單獨的上下文中；
溝通更加順暢，一個上下文可以明确自己對其他上下文的依賴關系，進而使得團隊内開發直接更好的對接。
從團隊間的關系來看，明确的上下文關系能夠帶來如下幫助：
每個團隊在它的上下文中能夠更加明确自己領域内的概念，因為上下文是領域的解系統；
對于限界上下文之間發生互動，團隊與上下文的一緻性，能夠保證我們明确對接的團隊和依賴的上下遊。
限界上下文之間的映射關系
合作關系（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。
子產品（Module）是DDD中明确提到的一種控制限界上下文的手段，在我們的工程中，一般盡量用一個子產品來表示一個領域的限界上下文。
如代碼中所示，一般的工程中包的組織方式為{com.公司名.組織架構.業務.上下文.*}，這樣的組織結構能夠明确的将一個上下文限定在包的内部。
代碼示範1 子產品的組織
對于子產品内的組織結構，一般情況下我們是按照領域對象、領域服務、領域資源庫、防腐層等組織方式定義的。
代碼示範2 子產品的組織
每個子產品的具體實作，我們将在下文中展開。
前文提到，領域驅動要解決的一個重要的問題，就是解決對象的貧血問題。這裡我們用之前定義的抽獎（DrawLottery）聚合根和獎池（AwardPool）值對象來具體說明。
抽獎聚合根持有了抽獎活動的id和該活動下的所有可用獎池清單，它的一個最主要的領域功能就是根據一個抽獎發生場景（DrawLotteryContext），選擇出一個适配的獎池，即chooseAwardPool方法。
chooseAwardPool的邏輯是這樣的：DrawLotteryContext會帶有使用者抽獎時的場景資訊（抽獎得分或抽獎時所在的城市），DrawLottery會根據這個場景資訊，比對一個可以給使用者發獎的AwardPool。
代碼示範3 DrawLottery
在比對到一個具體的獎池之後，需要确定最後給使用者的獎品是什麼。
這部分的領域功能在AwardPool内。
代碼示範4 AwardPool
與以往的僅有getter、setter的業務對象不同，領域對象具有了行為，對象更加豐滿。同時，比起将這些邏輯寫在服務内（例如**Service），領域功能的内聚性更強，職責更加明确。
領域對象需要資源存儲，存儲的手段可以是多樣化的，常見的無非是資料庫，分布式緩存，本地緩存等。資源庫（Repository）的作用，就是對領域的存儲和通路進行統一管理的對象。在抽獎平台中，我們是通過如下的方式組織資源庫的。
代碼示範5 Repository組織結構
資源庫對外的整體通路由Repository提供，它聚合了各個資源庫的資料資訊，同時也承擔了資源存儲的邏輯（例如緩存更新機制等）。
在抽獎資源庫中，我們屏蔽了對底層獎池和獎品的直接通路，而是僅對抽獎的聚合根進行資源管理。代碼示例中展示了抽獎資源擷取的方法（最常見的Cache Aside Pattern）。
比起以往将資源管理放在服務中的做法，由資源庫對資源進行管理，職責更加明确，代碼的可讀性和可維護性也更強。
代碼示範6 DrawLotteryRepository
亦稱适配層。在一個上下文中，有時需要對外部上下文進行通路，通常會引入防腐層的概念來對外部上下文的通路進行一次轉義。
有以下幾種情況會考慮引入防腐層：
需要将外部上下文中的模型翻譯成本上下文了解的模型。
不同上下文之間的團隊協作關系，如果是供奉者關系，建議引入防腐層，避免外部上下文變化對本上下文的侵蝕。
該通路本上下文使用廣泛，為了避免改動影響範圍過大。
如果内部多個上下文對外部上下文需要通路，那麼可以考慮将其放到通用上下文中。
在抽獎平台中，我們定義了使用者城市資訊防腐層
(UserCityInfoFacade)，用于外部的使用者城市資訊上下文（微服務架構下表現為使用者城市資訊服務）。
以使用者資訊防腐層舉例，它以抽獎請求參數(LotteryContext)為入參，以城市資訊(MtCityInfo)為輸出。
代碼示範7 UserCityInfoFacade
上文中，我們将領域行為封裝到領域對象中，将資源管理行為封裝到資源庫中，将外部上下文的互動行為封裝到防腐層中。此時，我們再回過頭來看領域服務時，能夠發現領域服務本身所承載的職責也就更加清晰了，即就是通過串聯領域對象、資源庫和防腐層等一系列領域内的對象的行為，對其他上下文提供互動的接口。
我們以抽獎服務為例（issueLottery），可以看到在省略了一些防禦性邏輯（異常處理，空值判斷等）後，領域服務的邏輯已經足夠清晰明了。
代碼示範8 LotteryService
在抽獎平台的實踐中，我們的資料流轉如上圖所示。
首先領域的開放服務通過資訊傳輸對象（DTO）來完成與外界的資料互動；在領域内部，我們通過領域對象（DO）作為領域内部的資料和行為載體；在資源庫内部，我們沿襲了原有的資料庫持久化對象（PO）進行資料庫資源的互動。同時，DTO與DO的轉換發生在領域服務内，DO與PO的轉換發生在資源庫内。
與以往的業務服務相比，目前的編碼規範可能多造成了一次資料轉換，但每種資料對象職責明确，資料流轉更加清晰。
通常內建上下文的手段有多種，常見的手段包括開放領域服務接口、開放HTTP服務以及消息釋出-訂閱機制。
在抽獎系統中，我們使用的是開放服務接口進行互動的。最明顯的展現是計數上下文，它作為一個通用上下文，對抽獎、風控、活動準入等上下文都提供了通路接口。
同時，如果在一個上下文對另一個上下文進行內建時，若需要一定的隔離和适配，可以引入防腐層的概念。這一部分的示例可以參考前文的防腐層代碼示例。
接下來講解在實施領域模型的過程中，如何應用到系統架構中。
我們采用的微服務架構風格，與Vernon在《實作領域驅動設計》并不太一緻，更具體差異可閱讀他的書體會。
如果我們維護一個從前到後的應用系統：
下圖中領域服務是使用微服務技術剝離開來，獨立部署，對外暴露的隻能是服務接口，領域對外暴露的業務邏輯隻能依托于領域服務。而在Vernon著作中，并未假定微服務架構風格，是以領域層暴露的除了領域服務外，還有聚合、實體和值對象等。此時的應用服務層是比較簡單的，擷取來自接口層的請求參數，排程多個領域服務以實作界面層功能。
随着業務發展，業務系統快速膨脹，我們的系統屬于核心時：
應用服務雖然沒有領域邏輯，但涉及到了對多個領域服務的編排。當業務規模龐大到一定程度，編排本身就富含了業務邏輯（除此之外，應用服務在穩定性、性能上所做的措施也希望統一起來，而非散落各處），那麼此時應用服務對于外部來說是一個領域服務，整體看起來則是一個獨立的限界上下文。
此時應用服務對内還屬于應用服務，對外已是領域服務的概念，需要将其暴露為微服務。
注：具體的架構實踐可按照團隊和業務的實際情況來，此處僅為作者自身的業務實踐。除分層架構外，如CQRS架構也是不錯的選擇
以下是一個示例。我們定義了抽獎、活動準入、風險控制等多個領域服務。在本系統中，我們需要內建多個領域服務，為用戶端提供一套功能完備的抽獎應用服務。這個應用服務的組織如下：
代碼示範9 LotteryApplicationService
<b>結語</b>
在本文中，我們采用了分治的思想，從抽象到具體闡述了DDD在網際網路真實業務系統中的實踐。通過領域驅動設計這個強大的武器，我們将系統解構的更加合理。
但值得注意的是，如果你面臨的系統很簡單或者做一些SmartUI之類，那麼你不一定需要DDD。盡管本文對貧血模型、演進式設計提出了些許看法，但它們在特定範圍和具體場景下會更高效。讀者需要針對自己的實際情況，做一定取舍，适合自己的才是最好的。
本篇通過DDD來講述軟體設計的術與器，本質是為了高内聚低耦合，緊靠本質，按自己的了解和團隊情況來實踐DDD即可。
另外，關于DDD在疊代過程中模型腐化的相關問題，本文中沒有提及，将在後續的文章中論述，敬請期待。
鑒于作者經驗有限，我們對領域驅動的了解難免會有不足之處，歡迎大家共同探讨，共同提高。
原文釋出時間為：2017-12-26
本文作者：文彬、子維@美團