貧血領域?qū)ο?#xff08;Anemic Domain Object）是指僅用作數(shù)據(jù)載體，而沒有行為和動作的領域?qū)ο蟆?/p>

在我們習慣了J2EE的開發(fā)模式后，Action/Service/DAO這種分層模式，會很自然地寫出過程式代碼，而學到的很多關于OO理論的也毫無用武之地。使用這種開發(fā)方式，對象只是數(shù)據(jù)的載體，沒有行為。以數(shù)據(jù)為中心，以數(shù)據(jù)庫ER設計作驅(qū)動。分層架構(gòu)在這種開發(fā)模式下，可以理解為是對數(shù)據(jù)移動、處理和實現(xiàn)的過程。

以筆者最近開發(fā)的系統(tǒng)抽獎平臺為例：

• 場景需求

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

• 貧血模型實現(xiàn)方案

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

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

• Service代碼實現(xiàn)

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

• 按照我們通常思路實現(xiàn)，可以發(fā)現(xiàn)：在業(yè)務領域里非常重要的抽獎，我的業(yè)務邏輯都是寫在Service中的，Award充其量只是個數(shù)據(jù)載體，沒有任何行為。簡單的業(yè)務系統(tǒng)采用這種貧血模型和過程化設計是沒有問題的，但在業(yè)務邏輯復雜了，業(yè)務邏輯、狀態(tài)會散落到在大量方法中，原本的代碼意圖會漸漸不明確，我們將這種情況稱為由貧血癥引起的失憶癥。

更好的是采用領域模型的開發(fā)方式，將數(shù)據(jù)和行為封裝在一起，并與現(xiàn)實世界中的業(yè)務對象相映射。各類具備明確的職責劃分，將領域邏輯分散到領域?qū)ο笾小＠^續(xù)舉我們上述抽獎的例子，使用概率選擇對應的獎品就應當放到AwardPool類中。

軟件系統(tǒng)復雜性應對

解決復雜和大規(guī)模軟件的武器可以被粗略地歸為三類：抽象、分治和知識。

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

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

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

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

與微服務架構(gòu)相得益彰

微服務架構(gòu)眾所周知，此處不做贅述。我們創(chuàng)建微服務時，需要創(chuàng)建一個高內(nèi)聚、低耦合的微服務。而DDD中的限界上下文則完美匹配微服務要求，可以將該限界上下文理解為一個微服務進程。

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

在系統(tǒng)復雜之后，我們都需要用分治來拆解問題。一般有兩種方式，技術(shù)維度和業(yè)務維度。技術(shù)維度是類似MVC這樣，業(yè)務維度則是指按業(yè)務領域來劃分系統(tǒng)。

微服務架構(gòu)更強調(diào)從業(yè)務維度去做分治來應對系統(tǒng)復雜度，而DDD也是同樣的著重業(yè)務視角。 如果兩者在追求的目標（業(yè)務維度）達到了上下文的統(tǒng)一，那么在具體做法上有什么聯(lián)系和不同呢？

我們將架構(gòu)設計活動精簡為以下三個層面：

• 業(yè)務架構(gòu)——根據(jù)業(yè)務需求設計業(yè)務模塊及其關系
• 系統(tǒng)架構(gòu)——設計系統(tǒng)和子系統(tǒng)的模塊
• 技術(shù)架構(gòu)——決定采用的技術(shù)及框架

以上三種活動在實際開發(fā)中是有先后順序的，但不一定孰先孰后。在我們解決常規(guī)套路問題時，我們會很自然地往熟悉的分層架構(gòu)套（先確定系統(tǒng)架構(gòu)），或者用PHP開發(fā)很快（先確定技術(shù)架構(gòu)），在業(yè)務不復雜時，這樣是合理的。

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

DDD的核心訴求就是將業(yè)務架構(gòu)映射到系統(tǒng)架構(gòu)上，在響應業(yè)務變化調(diào)整業(yè)務架構(gòu)時，也隨之變化系統(tǒng)架構(gòu)。而微服務追求業(yè)務層面的復用，設計出來的系統(tǒng)架構(gòu)和業(yè)務一致；在技術(shù)架構(gòu)上則系統(tǒng)模塊之間充分解耦，可以自由地選擇合適的技術(shù)架構(gòu)，去中心化地治理技術(shù)和數(shù)據(jù)。

可以參見下圖來更好地理解雙方之間的協(xié)作關系：

我們將通過上文提到的抽獎平臺，來詳細介紹我們?nèi)绾瓮ㄟ^DDD來解構(gòu)一個中型的基于微服務架構(gòu)的系統(tǒng)，從而做到系統(tǒng)的高內(nèi)聚、低耦合。

首先看下抽獎系統(tǒng)的大致需求： 運營——可以配置一個抽獎活動，該活動面向一個特定的用戶群體，并針對一個用戶群體發(fā)放一批不同類型的獎品（優(yōu)惠券，激活碼，實物獎品等）。 用戶-通過活動頁面參與不同類型的抽獎活動。

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

戰(zhàn)略建模

戰(zhàn)略和戰(zhàn)術(shù)設計是站在DDD的角度進行劃分。戰(zhàn)略設計側(cè)重于高層次、宏觀上去劃分和集成限界上下文，而戰(zhàn)術(shù)設計則關注更具體使用建模工具來細化上下文。

領域

現(xiàn)實世界中，領域包含了問題域和解系統(tǒng)。一般認為軟件是對現(xiàn)實世界的部分模擬。在DDD中，解系統(tǒng)可以映射為一個個限界上下文，限界上下文就是軟件對于問題域的一個特定的、有限的解決方案。

限界上下文

限界上下文

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

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

一個很形象的隱喻：細胞質(zhì)所以能夠存在，是因為細胞膜限定了什么在細胞內(nèi)，什么在細胞外，并且確定了什么物質(zhì)可以通過細胞膜。

劃分限界上下文

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

顯然我們不應該按技術(shù)架構(gòu)或者開發(fā)任務來創(chuàng)建限界上下文，應該按照語義的邊界來考慮。

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

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

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

產(chǎn)品的需求概述如下：

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

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

• 在設計初期，我們曾經(jīng)考慮劃分出抽獎和發(fā)獎兩個領域，前者負責選獎，后者負責將選中的獎品發(fā)放出去。但在實際開發(fā)過程中，我們發(fā)現(xiàn)這兩部分的邏輯緊密連接，難以拆分。并且單純的發(fā)獎邏輯足夠簡單，僅僅是調(diào)用第三方服務進行發(fā)獎，不足以獨立出來成為一個領域。

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

對于抽獎的獎品庫存量，由于庫存的行為與獎品本身相對解耦，庫存關注點更多是庫存內(nèi)容的核銷，且?guī)齑姹旧砭邆渫ㄓ眯?#xff0c;可以被獎品之外的內(nèi)容使用，因此我們定義了獨立的庫存上下文。

由于C端存在一些刷單行為，我們根據(jù)產(chǎn)品需求定義了風控上下文，用于對活動進行風控。 最后，活動準入、風控、抽獎等領域都涉及到一些次數(shù)的限制，因此我們定義了計數(shù)上下文。

可以看到，通過DDD的限界上下文劃分，我們界定出抽獎、活動準入、風控、計數(shù)、庫存等五個上下文，每個上下文在系統(tǒng)中都高度內(nèi)聚。

上下文映射圖

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

康威（梅爾·康威）定律

任何組織在設計一套系統(tǒng)（廣義概念上的系統(tǒng)）時，所交付的設計方案在結(jié)構(gòu)上都與該組織的溝通結(jié)構(gòu)保持一致。

康威定律告訴我們，系統(tǒng)結(jié)構(gòu)應盡量的與組織結(jié)構(gòu)保持一致。這里，我們認為團隊結(jié)構(gòu)（無論是內(nèi)部組織還是團隊間組織）就是組織結(jié)構(gòu)，限界上下文就是系統(tǒng)的業(yè)務結(jié)構(gòu)。因此，團隊結(jié)構(gòu)應該和限界上下文保持一致。

梳理清楚上下文之間的關系，從團隊內(nèi)部的關系來看，有如下好處：

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

限界上下文之間的映射關系

• 合作關系（Partnership）：兩個上下文緊密合作的關系，一榮俱榮，一損俱損。
• 共享內(nèi)核（Shared Kernel）：兩個上下文依賴部分共享的模型。
• 客戶方-供應方開發(fā)（Customer-Supplier Development）：上下文之間有組織的上下游依賴。
• 遵奉者（Conformist）：下游上下文只能盲目依賴上游上下文。
• 防腐層（Anticorruption Layer）：一個上下文通過一些適配和轉(zhuǎn)換與另一個上下文交互。
• 開放主機服務（Open Host Service）：定義一種協(xié)議來讓其他上下文來對本上下文進行訪問。
• 發(fā)布語言（Published Language）：通常與OHS一起使用，用于定義開放主機的協(xié)議。
• 大泥球（Big Ball of Mud）：混雜在一起的上下文關系，邊界不清晰。
• 另謀他路（SeparateWay）：兩個完全沒有任何聯(lián)系的上下文。

上文定義了上下文映射間的關系，經(jīng)過我們的反復斟酌，抽獎平臺上下文的映射關系圖如下：

由于抽獎，風控，活動準入，庫存，計數(shù)五個上下文都處在抽獎領域的內(nèi)部，所以它們之間符合“一榮俱榮，一損俱損”的合作關系（PartnerShip，簡稱PS）。

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

通過上下文映射關系，我們明確的限制了限界上下文的耦合性，即在抽獎平臺中，無論是上下文內(nèi)部交互（合作關系）還是與外部上下文交互（防腐層），耦合度都限定在數(shù)據(jù)耦合（Data Coupling）的層級。

戰(zhàn)術(shù)建模——細化上下文

梳理清楚上下文之間的關系后，我們需要從戰(zhàn)術(shù)層面上剖析上下文內(nèi)部的組織關系。首先看下DDD中的一些定義。

實體

當一個對象由其標識（而不是屬性）區(qū)分時，這種對象稱為實體（Entity）。

例：最簡單的，公安系統(tǒng)的身份信息錄入，對于人的模擬，即認為是實體，因為每個人是獨一無二的，且其具有唯一標識（如公安系統(tǒng)分發(fā)的身份證號碼）。

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

值對象

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

例：比如顏色信息，我們只需要知道{“name”:“黑色”，”css”:“#000000”}這樣的值信息就能夠滿足要求了，這避免了我們對標識追蹤帶來的系統(tǒng)復雜性。

值對象很重要，在習慣了使用數(shù)據(jù)庫的數(shù)據(jù)建模后，很容易將所有對象看作實體。使用值對象，可以更好地做系統(tǒng)優(yōu)化、精簡設計。

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

在實踐中，需要保證值對象創(chuàng)建后就不能被修改，即不允許外部再修改其屬性。在不同上下文集成時，會出現(xiàn)模型概念的公用，如商品模型會存在于電商的各個上下文中。在訂單上下文中如果你只關注下單時商品信息快照，那么將商品對象視為值對象是很好的選擇。

聚合根

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

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

聚合由根實體，值對象和實體組成。

如何創(chuàng)建好的聚合？

• 邊界內(nèi)的內(nèi)容具有一致性：在一個事務中只修改一個聚合實例。如果你發(fā)現(xiàn)邊界內(nèi)很難接受強一致，不管是出于性能或產(chǎn)品需求的考慮，應該考慮剝離出獨立的聚合，采用最終一致的方式。
• 設計小聚合：大部分的聚合都可以只包含根實體，而無需包含其他實體。即使一定要包含，可以考慮將其創(chuàng)建為值對象。
• 通過唯一標識來引用其他聚合或?qū)嶓w：當存在對象之間的關聯(lián)時，建議引用其唯一標識而非引用其整體對象。如果是外部上下文中的實體，引用其唯一標識或?qū)⑿枰膶傩詷?gòu)造值對象。 如果聚合創(chuàng)建復雜，推薦使用工廠方法來屏蔽內(nèi)部復雜的創(chuàng)建邏輯。

聚合內(nèi)部多個組成對象的關系可以用來指導數(shù)據(jù)庫創(chuàng)建，但不可避免存在一定的抗阻。如聚合中存在List<值對象>，那么在數(shù)據(jù)庫中建立1:N的關聯(lián)需要將值對象單獨建表，此時是有id的，建議不要將該id暴露到資源庫外部，對外隱蔽。

領域服務

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

當我們采用了微服務架構(gòu)風格，一切領域邏輯的對外暴露均需要通過領域服務來進行。如原本由聚合根暴露的業(yè)務邏輯也需要依托于領域服務。

領域事件

領域事件是對領域內(nèi)發(fā)生的活動進行的建模。

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

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

另外，在抽獎領域中，我們還會使用抽獎結(jié)果（SendResult）作為輸出信息，使用用戶領獎記錄（UserLotteryLog）作為領獎憑據(jù)和存根。

謹慎使用值對象

在實踐中，我們發(fā)現(xiàn)雖然一些領域?qū)ο蠓现祵ο蟮母拍?#xff0c;但是隨著業(yè)務的變動，很多原有的定義會發(fā)生變更，值對象可能需要在業(yè)務意義具有唯一標識，而對這類值對象的重構(gòu)往往需要較高成本。因此在特定的情況下，我們也要根據(jù)實際情況來權(quán)衡領域?qū)ο蟮倪x型。

DDD工程實現(xiàn)

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

模塊

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

如代碼中所示，一般的工程中包的組織方式為{com.公司名.組織架構(gòu).業(yè)務.上下文.*}，這樣的組織結(jié)構(gòu)能夠明確的將一個上下文限定在包的內(nèi)部。

代碼演示1 模塊的組織

對于模塊內(nèi)的組織結(jié)構(gòu)，一般情況下我們是按照領域?qū)ο蟆㈩I域服務、領域資源庫、防腐層等組織方式定義的。

代碼演示2 模塊的組織

每個模塊的具體實現(xiàn)，我們將在下文中展開。

資源庫

領域?qū)ο笮枰Y源存儲，存儲的手段可以是多樣化的，常見的無非是數(shù)據(jù)庫，分布式緩存，本地緩存等。資源庫（Repository）的作用，就是對領域的存儲和訪問進行統(tǒng)一管理的對象。在抽獎平臺中，我們是通過如下的方式組織資源庫的。

代碼演示5 Repository組織結(jié)構(gòu)

資源庫對外的整體訪問由Repository提供，它聚合了各個資源庫的數(shù)據(jù)信息，同時也承擔了資源存儲的邏輯（例如緩存更新機制等）。

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

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

代碼演示6 DrawLotteryRepository

防腐層

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

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

• 需要將外部上下文中的模型翻譯成本上下文理解的模型。
• 不同上下文之間的團隊協(xié)作關系，如果是供奉者關系，建議引入防腐層，避免外部上下文變化對本上下文的侵蝕。
• 該訪問本上下文使用廣泛，為了避免改動影響范圍過大。

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

在抽獎平臺中，我們定義了用戶城市信息防腐層(UserCityInfoFacade)，用于外部的用戶城市信息上下文（微服務架構(gòu)下表現(xiàn)為用戶城市信息服務）。

以用戶信息防腐層舉例，它以抽獎請求參數(shù)(LotteryContext)為入?yún)?#xff0c;以城市信息(MtCityInfo)為輸出。

代碼演示7 UserCityInfoFacade

領域服務

上文中，我們將領域行為封裝到領域?qū)ο笾?#xff0c;將資源管理行為封裝到資源庫中，將外部上下文的交互行為封裝到防腐層中。此時，我們再回過頭來看領域服務時，能夠發(fā)現(xiàn)領域服務本身所承載的職責也就更加清晰了，即就是通過串聯(lián)領域?qū)ο蟆①Y源庫和防腐層等一系列領域內(nèi)的對象的行為，對其他上下文提供交互的接口。

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

代碼演示8 LotteryService

數(shù)據(jù)流轉(zhuǎn)

在抽獎平臺的實踐中，我們的數(shù)據(jù)流轉(zhuǎn)如上圖所示。 首先領域的開放服務通過信息傳輸對象（DTO）來完成與外界的數(shù)據(jù)交互；在領域內(nèi)部，我們通過領域?qū)ο?#xff08;DO）作為領域內(nèi)部的數(shù)據(jù)和行為載體；在資源庫內(nèi)部，我們沿襲了原有的數(shù)據(jù)庫持久化對象（PO）進行數(shù)據(jù)庫資源的交互。同時，DTO與DO的轉(zhuǎn)換發(fā)生在領域服務內(nèi)，DO與PO的轉(zhuǎn)換發(fā)生在資源庫內(nèi)。

與以往的業(yè)務服務相比，當前的編碼規(guī)范可能多造成了一次數(shù)據(jù)轉(zhuǎn)換，但每種數(shù)據(jù)對象職責明確，數(shù)據(jù)流轉(zhuǎn)更加清晰。

上下文集成

通常集成上下文的手段有多種，常見的手段包括開放領域服務接口、開放HTTP服務以及消息發(fā)布-訂閱機制。

在抽獎系統(tǒng)中，我們使用的是開放服務接口進行交互的。最明顯的體現(xiàn)是計數(shù)上下文，它作為一個通用上下文，對抽獎、風控、活動準入等上下文都提供了訪問接口。 同時，如果在一個上下文對另一個上下文進行集成時，若需要一定的隔離和適配，可以引入防腐層的概念。這一部分的示例可以參考前文的防腐層代碼示例。

分離領域

接下來講解在實施領域模型的過程中，如何應用到系統(tǒng)架構(gòu)中。

我們采用的微服務架構(gòu)風格，與Vernon在《實現(xiàn)領域驅(qū)動設計》并不太一致，更具體差異可閱讀他的書體會。

如果我們維護一個從前到后的應用系統(tǒng)：

下圖中領域服務是使用微服務技術(shù)剝離開來，獨立部署，對外暴露的只能是服務接口，領域?qū)ν獗┞兜臉I(yè)務邏輯只能依托于領域服務。而在Vernon著作中，并未假定微服務架構(gòu)風格，因此領域?qū)颖┞兜某祟I域服務外，還有聚合、實體和值對象等。此時的應用服務層是比較簡單的，獲取來自接口層的請求參數(shù)，調(diào)度多個領域服務以實現(xiàn)界面層功能。

隨著業(yè)務發(fā)展，業(yè)務系統(tǒng)快速膨脹，我們的系統(tǒng)屬于核心時：

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

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

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

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

代碼演示9 LotteryApplicationService

在本文中，我們采用了分治的思想，從抽象到具體闡述了DDD在互聯(lián)網(wǎng)真實業(yè)務系統(tǒng)中的實踐。通過領域驅(qū)動設計這個強大的武器，我們將系統(tǒng)解構(gòu)的更加合理。

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

本篇通過DDD來講述軟件設計的術(shù)與器，本質(zhì)是為了高內(nèi)聚低耦合，緊靠本質(zhì)，按自己的理解和團隊情況來實踐DDD即可。

文章來源：https://tech.meituan.com/2017/12/22/ddd-in-practice.html

總結(jié)

以上是生活随笔為你收集整理的领域驱动设计在美团点评业务系统的实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。