概述
DDD（Domain-Driven Design 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）是由Eric Evans最先提出画株，目的是對(duì)軟件所涉及到的領(lǐng)域進(jìn)行建模，以應(yīng)對(duì)系統(tǒng)規(guī)模過大時(shí)引起的軟件復(fù)雜性的問題。整個(gè)過程大概是這樣的胆绊，開發(fā)團(tuán)隊(duì)和領(lǐng)域?qū)＜乙黄鹜ㄟ^ 通用語言(Ubiquitous Language)去理解和消化領(lǐng)域知識(shí)，從領(lǐng)域知識(shí)中提取和劃分為一個(gè)一個(gè)的子領(lǐng)域（核心子域聪轿，通用子域煤惩，支撐子域）嫉嘀，并在子領(lǐng)域上建立模型，再重復(fù)以上步驟魄揉，這樣周而復(fù)始剪侮，構(gòu)建出一套符合當(dāng)前領(lǐng)域的模型。
這里需要注意幾點(diǎn)：
- 通用語言是一個(gè)很泛的概念洛退，它作為一種溝通工具瓣俯，在開發(fā)團(tuán)隊(duì)內(nèi)部，開發(fā)團(tuán)隊(duì)與領(lǐng)域?qū)＜抑g使用兵怯。它包含了自然語言彩匕、文檔和圖表（不一定是標(biāo)準(zhǔn)的UML圖，只要能表達(dá)出領(lǐng)域知識(shí)的都可以）等內(nèi)容媒区。對(duì)通用語言中名詞驼仪，動(dòng)詞的使用需要認(rèn)真考量，因?yàn)檫@些名詞和動(dòng)詞會(huì)作為后面模型的指導(dǎo)命名袜漩。
- 通用語言中定義的術(shù)語在一個(gè) 限界上下文(bounded context)中不能存在二義性绪爸。同一個(gè)事物在不同的限界上下文中因?yàn)樗P(guān)注的側(cè)重點(diǎn)不同，所以所表達(dá)出的概念是不同的宙攻，但在同一個(gè)限界上下文中應(yīng)該表示的是一個(gè)概念奠货。比如用戶在微信中的聊天場(chǎng)景，朋友圈以及支付場(chǎng)景中所有表達(dá)的概念就應(yīng)該是不同的座掘，聊天場(chǎng)景關(guān)注的是用戶間的聊天內(nèi)容递惋，而支付場(chǎng)景關(guān)注的是用戶的賬戶余額。
- 一個(gè)子域可以包含多個(gè)限界上下文溢陪。
- 模型（Entity萍虽，值對(duì)象，Service形真，Aggregate root）是存在于限界上下文中的贩挣。
分層架構(gòu)
DDD中將系統(tǒng)分為UI層，應(yīng)用層没酣，領(lǐng)域?qū)右约盎A(chǔ)設(shè)施層。
上圖中卵迂，應(yīng)用層是很薄的一層裕便，因?yàn)樗回?fù)責(zé)接收UI層傳來的參數(shù)和路由到對(duì)應(yīng)的領(lǐng)域模型，它不負(fù)責(zé)處理具體的業(yè)務(wù)邏輯见咒。系統(tǒng)的業(yè)務(wù)邏輯放在了領(lǐng)域?qū)又谐ニィ裕I(lǐng)域?qū)釉谙到y(tǒng)架構(gòu)中占據(jù)了很大的面積。
在層級(jí)結(jié)構(gòu)中下翎，上層模塊調(diào)用下層模塊提供的服務(wù)缤言，這里就會(huì)存在一種依賴關(guān)系，Rebort C. Martin提出的依賴倒置原則大致是如下：
上層模塊不應(yīng)該依賴于下層模塊视事，兩者都應(yīng)該依賴于抽象胆萧；
抽象不應(yīng)該依賴于實(shí)現(xiàn)，實(shí)現(xiàn)應(yīng)該依賴于抽象;
這是一個(gè)面向接口編程的思想俐东，抽象說的是抽象類或接口跌穗，實(shí)現(xiàn)就是具體實(shí)現(xiàn)了這些抽象的實(shí)現(xiàn)類。翻譯成白話文是這樣的虏辫，上下層之間應(yīng)該通過接口來通訊蚌吸，接口定義的位置就決定了上下層的依賴關(guān)系是否倒置。比如Application層和Domain層進(jìn)行通訊砌庄，接口與接口的實(shí)現(xiàn)類都定義在Domain層中羹唠，這是正常的面向接口編程，不存在倒置關(guān)系娄昆。而Domain層和基礎(chǔ)設(shè)施層進(jìn)行通訊時(shí)佩微，原本是Domain層去依賴基礎(chǔ)設(shè)施層，如果我們將接口定義在Domain層稿黄，而實(shí)現(xiàn)類定義在基礎(chǔ)設(shè)施層喊衫，那么，基礎(chǔ)設(shè)施層就將依賴Domain層杆怕，這就是“倒置”這個(gè)詞的來由族购。實(shí)際上，我們?cè)谧鲞@樣分層架構(gòu)設(shè)計(jì)時(shí)陵珍，都是將接口定義在Domain層的寝杖。
DDD元素
在使用DDD設(shè)計(jì)系統(tǒng)時(shí)，主要包括Entity互纯，Value Object瑟幕，Service,Aggregate,Repository,Factory,Domain Event,Moudle等元素。
在建模時(shí)留潦，Entity可以用來代表一個(gè)事物只盹。既然Entity是用來代表一個(gè)事物的，那么它就應(yīng)該有一個(gè)唯一值來標(biāo)識(shí)這個(gè)事物兔院，同時(shí)殖卑，他還能記錄這個(gè)事物狀態(tài)的變化。比如：Id為5的Person對(duì)象坊萝，它的名字是張三孵稽，過兩天许起，他將自己的名字改為李四。但是菩鲜，這個(gè)人（Id=5）還是這個(gè)人（Id=5）园细，只是他名字的狀態(tài)以及發(fā)生了變化，而這個(gè)變化后的狀態(tài)被Person這個(gè)Entity記錄了下來接校。
Value Object是用來描述事物的某一方面的特征猛频，所以它是一個(gè)無狀態(tài)的，且是一個(gè)沒有標(biāo)識(shí)符的對(duì)象馅笙，這是和Entity的本質(zhì)區(qū)別伦乔。拿訂單來說，一張訂單在系統(tǒng)中應(yīng)該有一個(gè)唯一的標(biāo)識(shí)董习，且具有狀態(tài)烈和，所以訂單是一個(gè)Entity對(duì)象，而這張訂單共￥100元皿淋，則是描述了這個(gè)訂單的總額特征招刹，￥100元可以用值對(duì)象表示為{100，￥}窝趣，及金額和幣種的組合疯暑。{100，￥}在任何限界上下文中都描述的是￥100元哑舒，是因?yàn)樗麄儽容^的是里面的內(nèi)容（金額和幣種）妇拯，而上面的張三在修了名后，還是原來的那個(gè)人洗鸵，是因?yàn)樗容^的是唯一標(biāo)示ID的值越锈。
Aggregate是一組相關(guān)對(duì)象的集合，它作為數(shù)據(jù)修改的基本單元膘滨，為數(shù)據(jù)修改提供了一個(gè)邊界甘凭。每個(gè)聚合都有一個(gè)根和一個(gè)邊界，根也是一個(gè)實(shí)體火邓，聚合邊界以外的對(duì)象只能通過根對(duì)聚合內(nèi)部元素操作丹弱。聚合將一組相關(guān)的對(duì)象內(nèi)聚到一起，從而將系統(tǒng)的復(fù)雜程度降低铲咨。
repository用來存儲(chǔ)聚合躲胳，相當(dāng)于每一個(gè)聚合都應(yīng)該有一個(gè)倉庫實(shí)例。Entity和Value Object都應(yīng)該具有行為纤勒，而有些行為從語義上講泛鸟，不適合放到這兩個(gè)對(duì)象中，所以就單獨(dú)抽象了一個(gè)Service對(duì)象踊东，用來存放這些行為北滥。Factory是用來生成聚合的，當(dāng)生成一個(gè)聚合的步驟過于復(fù)雜時(shí)闸翅，可以將其生成過程放在工廠中再芋。
