至少30年以前晰赞，一些軟件設計人員就已經(jīng)意識到領域建模和設計的重要性稼病，并形成一種思潮，Eric Evans將其定義為領域驅(qū)動設計（Domain-Driven Design掖鱼，簡稱DDD）然走。在互聯(lián)網(wǎng)開發(fā)“小步快跑，迭代試錯”的大環(huán)境下戏挡，DDD似乎是一種比較“古老而緩慢”的思想芍瑞。然而，由于互聯(lián)網(wǎng)公司也逐漸深入實體經(jīng)濟褐墅，業(yè)務日益復雜拆檬，我們在開發(fā)中也越來越多地遇到傳統(tǒng)行業(yè)軟件開發(fā)中所面臨的問題。本文就先來講一下這些問題妥凳，然后再嘗試在實踐中用DDD的思想來解決這些問題竟贯。
過度耦合
業(yè)務初期，我們的功能大都非常簡單逝钥，普通的CRUD就能滿足屑那，此時系統(tǒng)是清晰的。隨著迭代的不斷演化艘款，業(yè)務邏輯變得越來越復雜持际，我們的系統(tǒng)也越來越冗雜。模塊彼此關聯(lián)哗咆，誰都很難說清模塊的具體功能意圖是啥蜘欲。修改一個功能時，往往光回溯該功能需要的修改點就需要很長時間晌柬，更別提修改帶來的不可預知的影響面姥份。
下圖是一個常見的系統(tǒng)耦合病例。
服務耦合示意圖
訂單服務接口中提供了查詢年碘、創(chuàng)建訂單相關的接口殿衰，也提供了訂單評價、支付盛泡、保險的接口闷祥。同時我們的表也是一個訂單大表，包含了非常多字段傲诵。在我們維護代碼時凯砍，牽一發(fā)而動全身，很可能只是想改下評價相關的功能拴竹，卻影響到了創(chuàng)單核心路徑悟衩。雖然我們可以通過測試保證功能完備性，但當我們在訂單領域有大量需求同時并行開發(fā)時栓拜，改動重疊座泳、惡性循環(huán)惠昔、疲于奔命修改各種問題。
上述問題挑势，歸根到底在于系統(tǒng)架構不清晰镇防，劃分出來的模塊內(nèi)聚度低、高耦合潮饱。
有一種解決方案来氧，按照演進式設計的理論，讓系統(tǒng)的設計隨著系統(tǒng)實現(xiàn)的增長而增長香拉。我們不需要作提前設計啦扬，就讓系統(tǒng)伴隨業(yè)務成長而演進。這當然是可行的凫碌，敏捷實踐中的重構扑毡、測試驅(qū)動設計及持續(xù)集成可以對付各種混亂問題。重構——保持行為不變的代碼改善清除了不協(xié)調(diào)的局部設計盛险，測試驅(qū)動設計確保對系統(tǒng)的更改不會導致系統(tǒng)丟失或破壞現(xiàn)有功能僚楞，持續(xù)集成則為團隊提供了同一代碼庫。
在這三種實踐中枉层，重構是克服演進式設計中大雜燴問題的主力泉褐，通過在單獨的類及方法級別上做一系列小步重構來完成。我們可以很容易重構出一個獨立的類來放某些通用的邏輯鸟蜡，但是你會發(fā)現(xiàn)你很難給它一個業(yè)務上的含義膜赃，只能給予一個技術維度描繪的含義。這會帶來什么問題呢揉忘？新同學并不總是知道對通用邏輯的改動或獲取來自該類跳座。顯然，制定項目規(guī)范并不是好的idea泣矛。我們又聞到了代碼即將腐敗的味道疲眷。
事實上，你可能意識到問題之所在您朽。在解決現(xiàn)實問題時狂丝，我們會將問題映射到腦海中的概念模型，在模型中解決問題哗总，再將解決方案轉(zhuǎn)換為實際的代碼几颜。上述問題在于我們解決了設計到代碼之間的重構，但提煉出來的設計模型讯屈，并不具有實際的業(yè)務含義蛋哭，這就導致在開發(fā)新需求時，其他同學并不能很自然地將業(yè)務問題映射到該設計模型涮母。設計似乎變成了重構者的自娛自樂谆趾，代碼繼續(xù)腐敗躁愿，重新重構……無休止的循環(huán)。
用DDD則可以很好地解決領域模型到設計模型的同步沪蓬、演化彤钟，最后再將反映了領域的設計模型轉(zhuǎn)為實際的代碼。
注：模型是我們解決實際問題所抽象出來的概念模型怜跑，領域模型則表達與業(yè)務相關的事實样勃；設計模型則描述了所要構建的系統(tǒng)吠勘。
貧血癥和失憶癥
貧血領域?qū)ο?/b>
貧血領域?qū)ο螅ˋnemic Domain Object）是指僅用作數(shù)據(jù)載體性芬，而沒有行為和動作的領域?qū)ο蟆?/p>
在我們習慣了J2EE的開發(fā)模式后，Action/Service/DAO這種分層模式剧防，會很自然地寫出過程式代碼植锉，而學到的很多關于OO理論的也毫無用武之地。使用這種開發(fā)方式峭拘，對象只是數(shù)據(jù)的載體俊庇，沒有行為。以數(shù)據(jù)為中心鸡挠，以數(shù)據(jù)庫ER設計作驅(qū)動辉饱。分層架構在這種開發(fā)模式下，可以理解為是對數(shù)據(jù)移動拣展、處理和實現(xiàn)的過程彭沼。
以筆者最近開發(fā)的系統(tǒng)抽獎平臺為例：
場景需求
獎池里配置了很多獎項，我們需要按運營預先配置的概率抽中一個獎項备埃。 實現(xiàn)非常簡單姓惑，生成一個隨機數(shù)，匹配符合該隨機數(shù)生成概率的獎項即可按脚。
貧血模型實現(xiàn)方案
先設計獎池和獎項的庫表配置于毙。
抽獎ER圖
設計AwardPool和Award兩個對象，只有簡單的get和set屬性的方法
class AwardPool {intawardPoolId;? ? List awards;public List<Award> getAwards() {returnawards;? ? }public void setAwards(List<Award> awards) {this.awards = awards;? ? }? ? ......}class Award {intawardId;intprobability;//概率......}
Service代碼實現(xiàn)
設計一個LotteryService辅搬，在其中的drawLottery()方法寫服務邏輯
AwardPool awardPool = awardPoolDao.getAwardPool(poolId);//sql查詢唯沮，將數(shù)據(jù)映射到AwardPool對象for(Award award : awardPool.getAwards()) {//尋找到符合award.getProbability()概率的award}
按照我們通常思路實現(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提供了這樣的知識手段，讓我們知道如何抽象出限界上下文以及如何去分治馍佑。
與微服務架構相得益彰
微服務架構眾所周知斋否，此處不做贅述。我們創(chuàng)建微服務時拭荤，需要創(chuàng)建一個高內(nèi)聚茵臭、低耦合的微服務。而DDD中的限界上下文則完美匹配微服務要求舅世，可以將該限界上下文理解為一個微服務進程旦委。
上述是從更直觀的角度來描述兩者的相似處奇徒。
在系統(tǒng)復雜之后，我們都需要用分治來拆解問題缨硝。一般有兩種方式摩钙，技術維度和業(yè)務維度。技術維度是類似MVC這樣查辩，業(yè)務維度則是指按業(yè)務領域來劃分系統(tǒng)胖笛。
微服務架構更強調(diào)從業(yè)務維度去做分治來應對系統(tǒng)復雜度，而DDD也是同樣的著重業(yè)務視角宜岛。 如果兩者在追求的目標（業(yè)務維度）達到了上下文的統(tǒng)一长踊，那么在具體做法上有什么聯(lián)系和不同呢？
我們將架構設計活動精簡為以下三個層面：
業(yè)務架構——根據(jù)業(yè)務需求設計業(yè)務模塊及其關系
系統(tǒng)架構——設計系統(tǒng)和子系統(tǒng)的模塊
技術架構——決定采用的技術及框架
以上三種活動在實際開發(fā)中是有先后順序的谬返，但不一定孰先孰后之斯。在我們解決常規(guī)套路問題時日杈，我們會很自然地往熟悉的分層架構套（先確定系統(tǒng)架構）遣铝，或者用PHP開發(fā)很快（先確定技術架構），在業(yè)務不復雜時莉擒，這樣是合理的酿炸。
跳過業(yè)務架構設計出來的架構關注點不在業(yè)務響應上，可能就是個大泥球涨冀，在面臨需求迭代或響應市場變化時就很痛苦填硕。
DDD的核心訴求就是將業(yè)務架構映射到系統(tǒng)架構上，在響應業(yè)務變化調(diào)整業(yè)務架構時鹿鳖，也隨之變化系統(tǒng)架構扁眯。而微服務追求業(yè)務層面的復用，設計出來的系統(tǒng)架構和業(yè)務一致翅帜；在技術架構上則系統(tǒng)模塊之間充分解耦姻檀，可以自由地選擇合適的技術架構，去中心化地治理技術和數(shù)據(jù)涝滴。
可以參見下圖來更好地理解雙方之間的協(xié)作關系：
DDD與微服務關系
我們將通過上文提到的抽獎平臺绣版，來詳細介紹我們?nèi)绾瓮ㄟ^DDD來解構一個中型的基于微服務架構的系統(tǒng)，從而做到系統(tǒng)的高內(nèi)聚歼疮、低耦合杂抽。
首先看下抽獎系統(tǒng)的大致需求： 運營——可以配置一個抽獎活動，該活動面向一個特定的用戶群體韩脏，并針對一個用戶群體發(fā)放一批不同類型的獎品（優(yōu)惠券缩麸，激活碼，實物獎品等）赡矢。 用戶-通過活動頁面參與不同類型的抽獎活動杭朱。
設計領域模型的一般步驟如下：
根據(jù)需求劃分出初步的領域和限界上下文愚屁，以及上下文之間的關系；
進一步分析每個上下文內(nèi)部痕檬，識別出哪些是實體霎槐，哪些是值對象；
對實體梦谜、值對象進行關聯(lián)和聚合丘跌，劃分出聚合的范疇和聚合根；
為聚合根設計倉儲唁桩，并思考實體或值對象的創(chuàng)建方式闭树；
在工程中實踐領域模型，并在實踐中檢驗模型的合理性荒澡，倒推模型中不足的地方并重構报辱。
戰(zhàn)略建模
戰(zhàn)略和戰(zhàn)術設計是站在DDD的角度進行劃分。戰(zhàn)略設計側(cè)重于高層次单山、宏觀上去劃分和集成限界上下文碍现，而戰(zhàn)術設計則關注更具體使用建模工具來細化上下文。
領域
現(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签则，在他們的大作里都沒有怎么提及须床。
顯然我們不應該按技術架構或者開發(fā)任務來創(chuàng)建限界上下文，應該按照語義的邊界來考慮渐裂。
我們的實踐是豺旬，考慮產(chǎn)品所講的通用語言，從中提取一些術語稱之為概念對象柒凉，尋找對象之間的聯(lián)系族阅；或者從需求里提取一些動詞，觀察動詞和對象之間的關系膝捞；我們將緊耦合的各自圈在一起坦刀，觀察他們內(nèi)在的聯(lián)系，從而形成對應的界限上下文蔬咬。形成之后鲤遥，我們可以嘗試用語言來描述下界限上下文的職責，看它是否清晰计盒、準確渴频、簡潔和完整芽丹。簡言之北启，限界上下文應該從需求出發(fā)，按領域劃分拔第。
前文提到咕村，我們的用戶劃分為運營和用戶。其中蚊俺，運營對抽獎活動的配置十分復雜但相對低頻懈涛。用戶對這些抽獎活動配置的使用是高頻次且無感知的。根據(jù)這樣的業(yè)務特點泳猬，我們首先將抽獎平臺劃分為C端抽獎和M端抽獎管理平臺兩個子域批钠，讓兩者完全解耦。
抽獎平臺領域
在確認了M端領域和C端的限界上下文后得封，我們再對各自上下文內(nèi)部進行限界上下文的劃分埋心。下面我們用C端進行舉例。
產(chǎn)品的需求概述如下：
1. 抽獎活動有活動限制忙上，例如用戶的抽獎次數(shù)限制拷呆，抽獎的開始和結束的時間等；2. 一個抽獎活動包含多個獎品，可以針對一個或多個用戶群體茬斧；3. 獎品有自身的獎品配置腰懂，例如庫存量，被抽中的概率等项秉，最多被一個用戶抽中的次數(shù)等等绣溜；4. 用戶群體有多種區(qū)別方式，如按照用戶所在城市區(qū)分娄蔼，按照新老客區(qū)分等涮毫；5. 活動具有風控配置，能夠限制用戶參與抽獎的頻率贷屎。
根據(jù)產(chǎn)品的需求罢防，我們提取了一些關鍵性的概念作為子域，形成我們的限界上下文唉侄。
C端抽獎領域
首先咒吐，抽獎上下文作為整個領域的核心，承擔著用戶抽獎的核心業(yè)務属划，抽獎中包含了獎品和用戶群體的概念恬叹。
在設計初期，我們曾經(jīng)考慮劃分出抽獎和發(fā)獎兩個領域同眯，前者負責選獎绽昼，后者負責將選中的獎品發(fā)放出去。但在實際開發(fā)過程中须蜗，我們發(fā)現(xiàn)這兩部分的邏輯緊密連接硅确，難以拆分。并且單純的發(fā)獎邏輯足夠簡單明肮，僅僅是調(diào)用第三方服務進行發(fā)獎菱农，不足以獨立出來成為一個領域。
對于活動的限制柿估，我們定義了活動準入的通用語言循未，將活動開始/結束時間，活動可參與次數(shù)等限制條件都收攏到活動準入上下文中秫舌。
對于抽獎的獎品庫存量的妖，由于庫存的行為與獎品本身相對解耦，庫存關注點更多是庫存內(nèi)容的核銷足陨，且?guī)齑姹旧砭邆渫ㄓ眯陨┧冢梢员华勂分獾膬?nèi)容使用，因此我們定義了獨立的庫存上下文钠右。
由于C端存在一些刷單行為赋元，我們根據(jù)產(chǎn)品需求定義了風控上下文，用于對活動進行風控。 最后搁凸，活動準入媚值、風控、抽獎等領域都涉及到一些次數(shù)的限制护糖，因此我們定義了計數(shù)上下文褥芒。
可以看到，通過DDD的限界上下文劃分嫡良，我們界定出抽獎锰扶、活動準入、風控寝受、計數(shù)坷牛、庫存等五個上下文，每個上下文在系統(tǒng)中都高度內(nèi)聚很澄。
上下文映射圖
在進行上下文劃分之后京闰，我們還需要進一步梳理上下文之間的關系。
康威（梅爾·康威）定律
任何組織在設計一套系統(tǒng)（廣義概念上的系統(tǒng)）時甩苛，所交付的設計方案在結構上都與該組織的溝通結構保持一致蹂楣。
康威定律告訴我們，系統(tǒng)結構應盡量的與組織結構保持一致讯蒲。這里痊土，我們認為團隊結構（無論是內(nèi)部組織還是團隊間組織）就是組織結構，限界上下文就是系統(tǒng)的業(yè)務結構墨林。因此赁酝，團隊結構應該和限界上下文保持一致。
梳理清楚上下文之間的關系萌丈，從團隊內(nèi)部的關系來看赞哗，有如下好處：
任務更好拆分，一個開發(fā)人員可以全身心的投入到相關的一個單獨的上下文中辆雾；
溝通更加順暢，一個上下文可以明確自己對其他上下文的依賴關系月劈，從而使得團隊內(nèi)開發(fā)直接更好的對接度迂。
從團隊間的關系來看，明確的上下文關系能夠帶來如下幫助：
每個團隊在它的上下文中能夠更加明確自己領域內(nèi)的概念，因為上下文是領域的解系統(tǒng)；
對于限界上下文之間發(fā)生交互弹渔，團隊與上下文的一致性内列，能夠保證我們明確對接的團隊和依賴的上下游。
限界上下文之間的映射關系
合作關系（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)術建奶言——細化上下文
梳理清楚上下文之間的關系后卒稳，我們需要從戰(zhàn)術層面上剖析上下文內(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é)點痴腌。
聚合是一個非常重要的概念雌团，核心領域往往都需要用聚合來表達。其次士聪，聚合在技術上有非常高的價值，可以指導詳細設計猛蔽。
聚合由根實體剥悟，值對象和實體組成灵寺。
如何創(chuàng)建好的聚合？
邊界內(nèi)的內(nèi)容具有一致性：在一個事務中只修改一個聚合實例区岗。如果你發(fā)現(xiàn)邊界內(nèi)很難接受強一致略板，不管是出于性能或產(chǎn)品需求的考慮，應該考慮剝離出獨立的聚合慈缔，采用最終一致的方式叮称。
設計小聚合：大部分的聚合都可以只包含根實體，而無需包含其他實體藐鹤。即使一定要包含瓤檐，可以考慮將其創(chuàng)建為值對象。
通過唯一標識來引用其他聚合或?qū)嶓w：當存在對象之間的關聯(lián)時娱节，建議引用其唯一標識而非引用其整體對象挠蛉。如果是外部上下文中的實體，引用其唯一標識或?qū)⑿枰膶傩詷嬙熘祵ο蟆?如果聚合創(chuàng)建復雜肄满，推薦使用工廠方法來屏蔽內(nèi)部復雜的創(chuàng)建邏輯谴古。
聚合內(nèi)部多個組成對象的關系可以用來指導數(shù)據(jù)庫創(chuàng)建，但不可避免存在一定的抗阻稠歉。如聚合中存在List<值對象>掰担，那么在數(shù)據(jù)庫中建立1:N的關聯(lián)需要將值對象單獨建表，此時是有id的怒炸，建議不要將該id暴露到資源庫外部带饱，對外隱蔽。
領域服務
一些重要的領域行為或操作横媚，可以歸類為領域服務纠炮。它既不是實體，也不是值對象的范疇灯蝴。
當我們采用了微服務架構風格恢口，一切領域邏輯的對外暴露均需要通過領域服務來進行。如原本由聚合根暴露的業(yè)務邏輯也需要依托于領域服務穷躁。
領域事件
領域事件是對領域內(nèi)發(fā)生的活動進行的建模耕肩。
抽獎平臺的核心上下文是抽獎上下文，接下來介紹下我們對抽獎上下文的建模问潭。
抽獎上下文
在抽獎上下文中猿诸，我們通過抽獎(DrawLottery)這個聚合根來控制抽獎行為，可以看到狡忙，一個抽獎包括了抽獎ID（LotteryId）以及多個獎池（AwardPool）梳虽，而一個獎池針對一個特定的用戶群體（UserGroup）設置了多個獎品（Award）。
另外灾茁，在抽獎領域中窜觉，我們還會使用抽獎結果（SendResult）作為輸出信息谷炸，使用用戶領獎記錄（UserLotteryLog）作為領獎憑據(jù)和存根。
謹慎使用值對象
在實踐中禀挫，我們發(fā)現(xiàn)雖然一些領域?qū)ο蠓现祵ο蟮母拍钛福请S著業(yè)務的變動，很多原有的定義會發(fā)生變更语婴，值對象可能需要在業(yè)務意義具有唯一標識描孟，而對這類值對象的重構往往需要較高成本。因此在特定的情況下砰左，我們也要根據(jù)實際情況來權衡領域?qū)ο蟮倪x型匿醒。
DDD工程實現(xiàn)
在對上下文進行細化后，我們開始在工程中真正落地DDD菜职。
模塊
模塊（Module）是DDD中明確提到的一種控制限界上下文的手段青抛，在我們的工程中，一般盡量用一個模塊來表示一個領域的限界上下文酬核。
如代碼中所示蜜另，一般的工程中包的組織方式為{com.公司名.組織架構.業(yè)務.上下文.*}，這樣的組織結構能夠明確的將一個上下文限定在包的內(nèi)部嫡意。
importcom.company.team.bussiness.lottery.*;//抽獎上下文importcom.company.team.bussiness.riskcontrol.*;//風控上下文importcom.company.team.bussiness.counter.*;//計數(shù)上下文importcom.company.team.bussiness.condition.*;//活動準入上下文importcom.company.team.bussiness.stock.*;//庫存上下文
代碼演示1 模塊的組織
對于模塊內(nèi)的組織結構举瑰，一般情況下我們是按照領域?qū)ο蟆㈩I域服務蔬螟、領域資源庫此迅、防腐層等組織方式定義的。
importcom.company.team.bussiness.lottery.domain.valobj.*;//領域?qū)ο?值對象importcom.company.team.bussiness.lottery.domain.entity.*;//領域?qū)ο?實體importcom.company.team.bussiness.lottery.domain.aggregate.*;//領域?qū)ο?聚合根importcom.company.team.bussiness.lottery.service.*;//領域服務importcom.company.team.bussiness.lottery.repo.*;//領域資源庫importcom.company.team.bussiness.lottery.facade.*;//領域防腐層
代碼演示2 模塊的組織
每個模塊的具體實現(xiàn)旧巾，我們將在下文中展開耸序。
領域?qū)ο?/p>
前文提到，領域驅(qū)動要解決的一個重要的問題鲁猩，就是解決對象的貧血問題坎怪。這里我們用之前定義的抽獎（DrawLottery）聚合根和獎池（AwardPool）值對象來具體說明。
抽獎聚合根持有了抽獎活動的id和該活動下的所有可用獎池列表廓握，它的一個最主要的領域功能就是根據(jù)一個抽獎發(fā)生場景（DrawLotteryContext）搅窿，選擇出一個適配的獎池，即chooseAwardPool方法隙券。
chooseAwardPool的邏輯是這樣的：DrawLotteryContext會帶有用戶抽獎時的場景信息（抽獎得分或抽獎時所在的城市）男应，DrawLottery會根據(jù)這個場景信息，匹配一個可以給用戶發(fā)獎的AwardPool娱仔。
packagecom.company.team.bussiness.lottery.domain.aggregate;import...;publicclass DrawLottery {privateintlotteryId;//抽獎idprivateList awardPools;//獎池列表//getter & setterpublic void setLotteryId(int lotteryId) {if(id<=0){thrownewIllegalArgumentException("非法的抽獎id");? ? ? ? }this.lotteryId = lotteryId;? ? }//根據(jù)抽獎入?yún)ontext選擇獎池public AwardPool chooseAwardPool(DrawLotteryContext context) {if(context.getMtCityInfo()!=null) {returnchooseAwardPoolByCityInfo(awardPools, context.getMtCityInfo());? ? ? ? }else{returnchooseAwardPoolByScore(awardPools, context.getGameScore());? ? ? ? }? ? }//根據(jù)抽獎所在城市選擇獎池private AwardPool chooseAwardPoolByCityInfo(List<AwardPool> awardPools, MtCifyInfo cityInfo) {for(AwardPool awardPool: awardPools) {if(awardPool.matchedCity(cityInfo.getCityId())) {returnawardPool;? ? ? ? ? ? }? ? ? ? }returnnull;? ? }//根據(jù)抽獎活動得分選擇獎池private AwardPool chooseAwardPoolByScore(List<AwardPool> awardPools, int gameScore) {...}}
代碼演示3 DrawLottery
在匹配到一個具體的獎池之后沐飘，需要確定最后給用戶的獎品是什么。這部分的領域功能在AwardPool內(nèi)牲迫。
packagecom.company.team.bussiness.lottery.domain.valobj;import...;publicclass AwardPool {privateString cityIds;//獎池支持的城市privateString scores;//獎池支持的得分privateintuserGroupType;//獎池匹配的用戶類型privateList awards;//獎池中包含的獎品//當前獎池是否與城市匹配public boolean matchedCity(int cityId) {...}//當前獎池是否與用戶得分匹配public boolean matchedScore(int score) {...}//根據(jù)概率選擇獎池public Award randomGetAward() {intsumOfProbablity =0;for(Award award: awards) {? ? ? ? ? ? sumOfProbability += award.getAwardProbablity();? ? ? ? }intrandomNumber = ThreadLocalRandom.current().nextInt(sumOfProbablity);? ? ? ? range =0;for(Award award: awards) {? ? ? ? ? ? range += award.getProbablity();if(randomNumber
代碼演示4 AwardPool
與以往的僅有getter薪铜、setter的業(yè)務對象不同众弓，領域?qū)ο缶哂辛诵袨槎鹘Γ瑢ο蟾迂S滿隔箍。同時，比起將這些邏輯寫在服務內(nèi)（例如**Service）脚乡，領域功能的內(nèi)聚性更強蜒滩，職責更加明確。
資源庫
領域?qū)ο笮枰Y源存儲奶稠，存儲的手段可以是多樣化的俯艰，常見的無非是數(shù)據(jù)庫，分布式緩存锌订，本地緩存等竹握。資源庫（Repository）的作用，就是對領域的存儲和訪問進行統(tǒng)一管理的對象辆飘。在抽獎平臺中啦辐，我們是通過如下的方式組織資源庫的。
//數(shù)據(jù)庫資源importcom.company.team.bussiness.lottery.repo.dao.AwardPoolDao;//數(shù)據(jù)庫訪問對象-獎池importcom.company.team.bussiness.lottery.repo.dao.AwardDao;//數(shù)據(jù)庫訪問對象-獎品importcom.company.team.bussiness.lottery.repo.dao.po.AwardPO;//數(shù)據(jù)庫持久化對象-獎品importcom.company.team.bussiness.lottery.repo.dao.po.AwardPoolPO;//數(shù)據(jù)庫持久化對象-獎池importcom.company.team.bussiness.lottery.repo.cache.DrawLotteryCacheAccessObj;//分布式緩存訪問對象-抽獎緩存訪問importcom.company.team.bussiness.lottery.repo.repository.DrawLotteryRepository;//資源庫訪問對象-抽獎資源庫
代碼演示5 Repository組織結構
資源庫對外的整體訪問由Repository提供芹关，它聚合了各個資源庫的數(shù)據(jù)信息，同時也承擔了資源存儲的邏輯（例如緩存更新機制等）紧卒。
在抽獎資源庫中，我們屏蔽了對底層獎池和獎品的直接訪問坡倔，而是僅對抽獎的聚合根進行資源管理征堪。代碼示例中展示了抽獎資源獲取的方法（最常見的Cache Aside Pattern）。
比起以往將資源管理放在服務中的做法疆液，由資源庫對資源進行管理，職責更加明確，代碼的可讀性和可維護性也更強冰单。
packagecom.company.team.bussiness.lottery.repo;import...;@Repositorypublicclass DrawLotteryRepository {@AutowiredprivateAwardDao awardDao;@AutowiredprivateAwardPoolDao awardPoolDao;@AutoWiredprivateDrawLotteryCacheAccessObj drawLotteryCacheAccessObj;public DrawLottery getDrawLotteryById(int lotteryId) {? ? ? ? DrawLottery drawLottery = drawLotteryCacheAccessObj.get(lotteryId);if(drawLottery!=null){returndrawLottery;? ? ? ? }? ? ? ? drawLottery = getDrawLotteyFromDB(lotteryId);? ? ? ? drawLotteryCacheAccessObj.add(lotteryId, drawLottery);returndrawLottery;? ? }private DrawLottery getDrawLotteryFromDB(int lotteryId) {...}}
代碼演示6 DrawLotteryRepository
防腐層
亦稱適配層坏晦。在一個上下文中狼荞，有時需要對外部上下文進行訪問，通常會引入防腐層的概念來對外部上下文的訪問進行一次轉(zhuǎn)義抱既。
有以下幾種情況會考慮引入防腐層：
需要將外部上下文中的模型翻譯成本上下文理解的模型。
不同上下文之間的團隊協(xié)作關系扁誓，如果是供奉者關系防泵，建議引入防腐層，避免外部上下文變化對本上下文的侵蝕蝗敢。
該訪問本上下文使用廣泛捷泞，為了避免改動影響范圍過大。
如果內(nèi)部多個上下文對外部上下文需要訪問前普，那么可以考慮將其放到通用上下文中肚邢。
在抽獎平臺中，我們定義了用戶城市信息防腐層(UserCityInfoFacade)，用于外部的用戶城市信息上下文（微服務架構下表現(xiàn)為用戶城市信息服務）骡湖。
以用戶信息防腐層舉例贱纠，它以抽獎請求參數(shù)(LotteryContext)為入?yún)ⅲ猿鞘行畔?MtCityInfo)為輸出响蕴。
packagecom.company.team.bussiness.lottery.facade;import...;@Componentpublicclass UserCityInfoFacade {@AutowiredprivateLbsService lbsService;//外部用戶城市信息RPC服務public MtCityInfo getMtCityInfo(LotteryContext context) {? ? ? ? LbsReq lbsReq =newLbsReq();? ? ? ? lbsReq.setLat(context.getLat());? ? ? ? lbsReq.setLng(context.getLng());? ? ? ? LbsResponse resp = lbsService.getLbsCityInfo(lbsReq);returnbuildMtCifyInfo(resp);? ? }private MtCityInfo buildMtCityInfo(LbsResponse resp) {...}}
代碼演示7 UserCityInfoFacade
領域服務
上文中谆焊，我們將領域行為封裝到領域?qū)ο笾校瑢①Y源管理行為封裝到資源庫中浦夷，將外部上下文的交互行為封裝到防腐層中辖试。此時，我們再回過頭來看領域服務時劈狐，能夠發(fā)現(xiàn)領域服務本身所承載的職責也就更加清晰了罐孝，即就是通過串聯(lián)領域?qū)ο蟆①Y源庫和防腐層等一系列領域內(nèi)的對象的行為肥缔，對其他上下文提供交互的接口莲兢。
我們以抽獎服務為例（issueLottery），可以看到在省略了一些防御性邏輯（異常處理续膳，空值判斷等）后改艇，領域服務的邏輯已經(jīng)足夠清晰明了。
packagecom.company.team.bussiness.lottery.service.implimport...;@Servicepublicclass LotteryServiceImpl implements LotteryService {@AutowiredprivateDrawLotteryRepository drawLotteryRepo;@AutowiredprivateUserCityInfoFacade UserCityInfoFacade;@AutowiredprivateAwardSendService awardSendService;@AutowiredprivateAwardCounterFacade awardCounterFacade;@Overridepublic IssueResponse issueLottery(LotteryContext lotteryContext) {? ? ? ? DrawLottery drawLottery = drawLotteryRepo.getDrawLotteryById(lotteryContext.getLotteryId());//獲取抽獎配置聚合根awardCounterFacade.incrTryCount(lotteryContext);//增加抽獎計數(shù)信息AwardPool awardPool = lotteryConfig.chooseAwardPool(bulidDrawLotteryContext(drawLottery, lotteryContext));//選中獎池Award award = awardPool.randomChooseAward();//選中獎品returnbuildIssueResponse(awardSendService.sendAward(award, lotteryContext));//發(fā)出獎品實體}private IssueResponse buildIssueResponse(AwardSendResponse awardSendResponse) {...}}
代碼演示8 LotteryService
數(shù)據(jù)流轉(zhuǎn)
need-to-insert-img
數(shù)據(jù)流轉(zhuǎn)
在抽獎平臺的實踐中坟岔，我們的數(shù)據(jù)流轉(zhuǎn)如上圖所示谒兄。 首先領域的開放服務通過信息傳輸對象（DTO）來完成與外界的數(shù)據(jù)交互；在領域內(nèi)部社付，我們通過領域?qū)ο螅―O）作為領域內(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)架構中。
我們采用的微服務架構風格碰声，與Vernon在《實現(xiàn)領域驅(qū)動設計》并不太一致诡蜓，更具體差異可閱讀他的書體會。
如果我們維護一個從前到后的應用系統(tǒng)：
下圖中領域服務是使用微服務技術剝離開來奥邮，獨立部署万牺，對外暴露的只能是服務接口，領域?qū)ν獗┞兜臉I(yè)務邏輯只能依托于領域服務洽腺。而在Vernon著作中，并未假定微服務架構風格覆旱，因此領域?qū)颖┞兜某祟I域服務外蘸朋，還有聚合、實體和值對象等扣唱。此時的應用服務層是比較簡單的藕坯，獲取來自接口層的請求參數(shù)，調(diào)度多個領域服務以實現(xiàn)界面層功能噪沙。
need-to-insert-img
DDD-分層
隨著業(yè)務發(fā)展炼彪，業(yè)務系統(tǒng)快速膨脹，我們的系統(tǒng)屬于核心時：
應用服務雖然沒有領域邏輯正歼，但涉及到了對多個領域服務的編排辐马。當業(yè)務規(guī)模龐大到一定程度，編排本身就富含了業(yè)務邏輯（除此之外局义，應用服務在穩(wěn)定性喜爷、性能上所做的措施也希望統(tǒng)一起來，而非散落各處）萄唇，那么此時應用服務對于外部來說是一個領域服務檩帐，整體看起來則是一個獨立的限界上下文。
此時應用服務對內(nèi)還屬于應用服務另萤，對外已是領域服務的概念湃密，需要將其暴露為微服務。
need-to-insert-img
DDD-系統(tǒng)架構圖
注：具體的架構實踐可按照團隊和業(yè)務的實際情況來，此處僅為作者自身的業(yè)務實踐泛源。除分層架構外拔妥，如CQRS架構也是不錯的選擇
以下是一個示例。我們定義了抽獎俩由、活動準入毒嫡、風險控制等多個領域服務。在本系統(tǒng)中幻梯，我們需要集成多個領域服務兜畸，為客戶端提供一套功能完備的抽獎應用服務。這個應用服務的組織如下：
package...;import...;@Servicepublicclass LotteryApplicationService {@AutowiredprivateLotteryRiskService riskService;@AutowiredprivateLotteryConditionService conditionService;@AutowiredprivateLotteryService lotteryService;//用戶參與抽獎活動public Response<PrizeInfo, ErrorData> participateLottery(LotteryContext lotteryContext) {//校驗用戶登錄信息validateLoginInfo(lotteryContext);//校驗風控 RiskAccessToken riskToken = riskService.accquire(buildRiskReq(lotteryContext));? ? ? ? ...//活動準入檢查LotteryConditionResult conditionResult = conditionService.checkLotteryCondition(otteryContext.getLotteryId(),lotteryContext.getUserId());? ? ? ? ...//抽獎并返回結果IssueResponse issueResponse = lotteryService.issurLottery(lotteryContext);if(issueResponse!=null&& issueResponse.getCode()==IssueResponse.OK) {returnbuildSuccessResponse(issueResponse.getPrizeInfo());? ? ? ? }else{returnbuildErrorResponse(ResponseCode.ISSUE_LOTTERY_FAIL, ResponseMsg.ISSUE_LOTTERY_FAIL)? ? ? ? }? ? }private void validateLoginInfo(LotteryContext lotteryContext){...}private Response<PrizeInfo, ErrorData> buildErrorResponse (int code, String msg){...}private Response<PrizeInfo, ErrorData> buildSuccessResponse (PrizeInfo prizeInfo){...}}
代碼演示9 LotteryApplicationService
在本文中碘梢，我們采用了分治的思想咬摇，從抽象到具體闡述了DDD在互聯(lián)網(wǎng)真實業(yè)務系統(tǒng)中的實踐。通過領域驅(qū)動設計這個強大的武器煞躬，我們將系統(tǒng)解構的更加合理肛鹏。
但值得注意的是，如果你面臨的系統(tǒng)很簡單或者做一些SmartUI之類恩沛，那么你不一定需要DDD在扰。盡管本文對貧血模型、演進式設計提出了些許看法雷客，但它們在特定范圍和具體場景下會更高效芒珠。讀者需要針對自己的實際情況，做一定取舍搅裙，適合自己的才是最好的皱卓。
本篇通過DDD來講述軟件設計的術與器，本質(zhì)是為了高內(nèi)聚低耦合部逮，緊靠本質(zhì)娜汁，按自己的理解和團隊情況來實踐DDD即可。
另外兄朋，關于DDD在迭代過程中模型腐化的相關問題掐禁，本文中沒有提及，將在后續(xù)的文章中論述蜈漓，敬請期待穆桂。
鑒于作者經(jīng)驗有限，我們對領域驅(qū)動的理解難免會有不足之處融虽，歡迎大家共同探討享完，共同提高。
