7.1什么是DDD

DDD是Eric Evans在2003年出版的《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)：軟件核心復(fù)雜性應(yīng)對(duì)之道》（Domain-Driven Design: Tackling Complexity in the Heart of Software）一書中提出的具有劃時(shí)代意義的重要概念，是指通過統(tǒng)一語言、業(yè)務(wù)抽象、領(lǐng)域劃分和領(lǐng)域建模等一系列手段來控制軟件復(fù)雜度的方法論。

DDD的革命性在于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)是面向?qū)ο蠓治龅姆椒ㄕ?，它可以利用面向?qū)ο蟮奶匦裕ǚ庋b、多態(tài)）有效地化解復(fù)雜性，而傳統(tǒng)J2EE或Spring+Hibernate等事務(wù)性編程模型只關(guān)心數(shù)據(jù)。這些數(shù)據(jù)對(duì)象除了簡(jiǎn)單的setter/getter方法外，不包含任何業(yè)務(wù)邏輯，業(yè)務(wù)邏輯都是以過程式的代碼寫在Service中。這種方式極易上手，但隨著業(yè)務(wù)的發(fā)展，系統(tǒng)也很容易變得混亂復(fù)雜。

7.2初步體驗(yàn)DDD

在介紹DDD之前，我喜歡用這個(gè)銀行轉(zhuǎn)賬的案例來做一個(gè)DDD和事務(wù)腳本（Transaction Script）的簡(jiǎn)單對(duì)比。我們要實(shí)現(xiàn)一個(gè)銀行轉(zhuǎn)賬的功能，如果用傳統(tǒng)的事務(wù)腳本方式實(shí)現(xiàn)，業(yè)務(wù)邏輯通常會(huì)被寫在MoneyTransferService中，而Account僅僅是getters和setters的數(shù)據(jù)結(jié)構(gòu)，也就是所謂的“貧血模式”。其代碼如下所示：

publicclassMoneyTransferServiceTransactionScriptImpl
implementsMoneyTransferService{
privateAccountDaoaccountDao;
privateBankingTransactionRepositorybankingTransactionRepository;
...
@Override
publicBankingTransactiontransfer(
StringfromAccountId,StringtoAccountId,doubleamount){
AccountfromAccount=accountDao.findById(fromAccountId);
AccounttoAccount=accountDao.findById(toAccountId);
...
doublenewBalance=fromAccount.getBalance()-amount;
switch(fromAccount.getOverdraftPolicy()){
caseNEVER:
if(newBalance

	

	上述代碼有些讀者可能會(huì)比較眼熟，因?yàn)榇蟛糠窒到y(tǒng)都是這么寫的。評(píng)審?fù)晷枨螅?a  target="_blank">工程師畫幾張UML圖完成設(shè)計(jì)，就開始像上面這樣寫業(yè)務(wù)代碼了，這樣寫基本不用太動(dòng)腦筋，完全是過程式的代碼風(fēng)格。

	同樣的業(yè)務(wù)邏輯，接下來看使用領(lǐng)域建模是怎么做的。在使用DDD之后，Account實(shí)體除賬號(hào)屬性之外，還包含了行為和業(yè)務(wù)邏輯，比如debit()和credit()方法。

	
publicclassAccount{
privateStringid;
privatedoublebalance;
privateOverdraftPolicyoverdraftPolicy;
...
publicdoublebalance(){returnbalance;}
publicvoiddebit(doubleamount){
this.overdraftPolicy.preDebit(this,amount);
this.balance=this.balance-amount;
this.overdraftPolicy.postDebit(this,amount);
}
publicvoidcredit(doubleamount){
this.balance=this.balance+amount;
}}


	

	透支策略O(shè)verdraftPolicy也不僅僅是一個(gè)Enum了，而是被抽象成包含業(yè)務(wù)規(guī)則并采用策略模式的對(duì)象。

	
publicinterfaceOverdraftPolicy{
voidpreDebit(Accountaccount,doubleamount);
voidpostDebit(Accountaccount,doubleamount);}publicclassNoOverdraftAllowedimplementsOverdraftPolicy{
publicvoidpreDebit(Accountaccount,doubleamount){
doublenewBalance=account.balance()-amount;
if(newBalance

	

	而Domain Service只需要調(diào)用Domain Entity對(duì)象完成業(yè)務(wù)邏輯。

	
publicclassMoneyTransferServiceDomainModelImpl
implementsMoneyTransferService{
privateAccountRepositoryaccountRepository;
privateBankingTransactionRepositorybankingTransactionRepository;
...
@Override
publicBankingTransactiontransfer(
StringfromAccountId,StringtoAccountId,doubleamount){
AccountfromAccount=accountRepository.findById(fromAccountId);
AccounttoAccount=accountRepository.findById(toAccountId);
...
fromAccount.debit(amount);
toAccount.credit(amount);
BankingTransactionmoneyTransferTransaction=
newMoneyTranferTransaction(fromAccountId,toAccountId,amount);
bankingTransactionRepository.addTransaction(moneyTransferTransaction);
returnmoneyTransferTransaction;
}}


	

	通過DDD重構(gòu)后，雖然類的數(shù)量比以前多了一些，但是每個(gè)類的職責(zé)更加單一，代碼的可讀性和可擴(kuò)展性也隨之提高。

	基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

	項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud

	視頻教程：https://doc.iocoder.cn/video/

	7.3數(shù)據(jù)驅(qū)動(dòng)和領(lǐng)域驅(qū)動(dòng)

	7.3.1數(shù)據(jù)驅(qū)動(dòng)

	目前主流的開發(fā)模式是由數(shù)據(jù)驅(qū)動(dòng)的。數(shù)據(jù)驅(qū)動(dòng)的開發(fā)很容易上手，

	有了業(yè)務(wù)需求，創(chuàng)建數(shù)據(jù)庫表，然后編寫業(yè)務(wù)邏輯，開發(fā)過程如圖7-1所示。數(shù)據(jù)驅(qū)動(dòng)以數(shù)據(jù)庫為中心，其中最重要的設(shè)計(jì)是數(shù)據(jù)模型，但隨著業(yè)務(wù)的增長(zhǎng)和項(xiàng)目的推進(jìn)，軟件開發(fā)和維護(hù)的難度會(huì)急劇增加。

	


	圖7-1數(shù)據(jù)驅(qū)動(dòng)研發(fā)過程

	以客戶關(guān)系管理（Customer Relationship Management，CRM）為例，其中很重要的概念有銷售、機(jī)會(huì)、客戶、私海、公海，實(shí)體的定義分別如下。

	銷售（Sales）：公司的銷售人員，一個(gè)銷售可以擁有多個(gè)銷售機(jī)會(huì)。

	機(jī)會(huì)（Opportunity）：銷售機(jī)會(huì)，每個(gè)機(jī)會(huì)包含至少一個(gè)客戶信息，且歸屬于一個(gè)銷售人員。

	客戶（Customer）：客戶，也就是銷售的對(duì)象。

	私海（Private sea）：專屬于某個(gè)銷售人員的領(lǐng)地（Territory），私海里面的客戶，其他銷售人員不能觸碰。

	公海（Public sea）：公共的領(lǐng)地，所有銷售人員都可以從公海里撿入客戶到其私海。

	按照我們?cè)?jīng)學(xué)習(xí)的數(shù)據(jù)庫建模理論，對(duì)于上面的場(chǎng)景，不難畫出圖7-2所示的實(shí)體聯(lián)系（Entity Relationship，ER）圖。

	


	圖7-2CRM的ER圖

	可以看到，圖7-2所示的ER圖中不存在公海和私海，因?yàn)樗^的機(jī)會(huì)在私海，就是這個(gè)機(jī)會(huì)是不是歸屬某個(gè)銷售，這樣我們只需要看機(jī)會(huì)上是否有salesId。如果有，說明機(jī)會(huì)被某個(gè)銷售占有，也就是在私海中；反之，這個(gè)機(jī)會(huì)就在公海中。

	在這種開發(fā)模式下，最后的產(chǎn)出是幾張數(shù)據(jù)庫表，以及針對(duì)表中數(shù)據(jù)進(jìn)行操作的事務(wù)腳本，如圖7-3所示。

	


	圖7-3事務(wù)腳本實(shí)現(xiàn)

	7.3.2領(lǐng)域驅(qū)動(dòng)

	領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)關(guān)心的是業(yè)務(wù)中的領(lǐng)域劃分（戰(zhàn)略設(shè)計(jì)）和領(lǐng)域建模（戰(zhàn)術(shù)設(shè)計(jì)），其開發(fā)過程不再以數(shù)據(jù)模型為起點(diǎn)，而是以領(lǐng)域模型為出發(fā)點(diǎn)，研發(fā)過程如圖7-4所示。領(lǐng)域模型對(duì)應(yīng)的是業(yè)務(wù)實(shí)體，在程序中主要表現(xiàn)為類、聚合根和值對(duì)象，它更加關(guān)注業(yè)務(wù)語義的顯性化表達(dá)，而不是數(shù)據(jù)的存儲(chǔ)和數(shù)據(jù)之間的關(guān)系。 這是“領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)”和“數(shù)據(jù)驅(qū)動(dòng)設(shè)計(jì)”之間顯著的區(qū)別。

	


	圖7-4領(lǐng)域驅(qū)動(dòng)研發(fā)過程

	仍以上面的CRM為例。假如我們先不考慮數(shù)據(jù)模型，而是采用面向?qū)ο蠓治觯∣bject Oriented Analysis，OOA）對(duì)這個(gè)場(chǎng)景進(jìn)行領(lǐng)域建模，那么可以得到圖7-5所示的領(lǐng)域模型。

	


	圖7-5CRM的領(lǐng)域模型

	可以看到，在圖7-5中，領(lǐng)域模型的描述更加貼近業(yè)務(wù)，一些重要的業(yè)務(wù)術(shù)語和概念沒有丟失，更完整地表達(dá)了業(yè)務(wù)語義。即使是產(chǎn)品經(jīng)理或者業(yè)務(wù)人員，也不難看懂這樣的領(lǐng)域模型，甚至他們可以和技術(shù)人員一起參與到梳理領(lǐng)域模型和創(chuàng)建活動(dòng)中來。

	通過DDD的戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)，我們可以為問題域劃分出合適的子域，并對(duì)域中的業(yè)務(wù)進(jìn)行建模。圖7-6所示是我們?cè)趯?shí)際工作中為CRM進(jìn)行的領(lǐng)域戰(zhàn)略設(shè)計(jì)。

	


	圖7-6CRM的領(lǐng)域劃分

	7.3.3ORM

	很明顯，領(lǐng)域模型和數(shù)據(jù)模型并不是一一對(duì)應(yīng)的關(guān)系，但也不排除，有些情況領(lǐng)域模型和數(shù)據(jù)模型是趨同的，但是大部分情況都需要做一層映射（Mapping）。為了彌補(bǔ)二者之間的差異，行業(yè)先驅(qū)們做了很多關(guān)于映射工作的嘗試，這種技術(shù)有一個(gè)名稱叫作對(duì)象關(guān)系映射（Object Relationship Mapping，ORM），如圖7-7所示。

	


	圖7-7對(duì)象關(guān)系映射

	ORM曾經(jīng)非?；穑浀卯?dāng)年Hibernate才出現(xiàn)時(shí)，我用盡了其中的高級(jí)技巧，比如繼承關(guān)系映射、多對(duì)多關(guān)系映射……結(jié)果弄出來的東西卻變成了“四不像”，既不像Entity，也不像數(shù)據(jù)對(duì)象（Data Object，DO）。

	ORM的問題在于它太理想化，期望通過工具把數(shù)據(jù)建模和領(lǐng)域建模合一，這樣的嘗試注定是很難成功的。仍以上述的CRM案例為例，在數(shù)據(jù)模型中根本就沒有私海和公海這兩個(gè)實(shí)體，工具是無法映射的。因此，Hibernate和JPA的衰落是可以預(yù)見的?，F(xiàn)在使用最多的是MyBatis，它很簡(jiǎn)單，完全不理會(huì)復(fù)雜的關(guān)系和對(duì)象之間的復(fù)雜關(guān)系映射，只做數(shù)據(jù)庫表和DO之間的簡(jiǎn)單映射。

	復(fù)雜的數(shù)據(jù)庫關(guān)系和對(duì)象關(guān)系之間的差異，其本質(zhì)是數(shù)據(jù)模型和領(lǐng)域模型之間的差異，而這種差異的多樣性和靈活性是很難通過規(guī)則預(yù)先定義的，這也是為什么工具的作用會(huì)很有限?，F(xiàn)在的互聯(lián)網(wǎng)大廠大多使用MyBatis，原因也在于此。因此，如果你打算實(shí)踐DDD，請(qǐng)一定不要讓工具幫你去建模，工具不會(huì)抽象，也不會(huì)思考，還是要老老實(shí)實(shí)自己動(dòng)手去建。

	





	審核編輯：劉清