494      阿裏雲  技術社區[雲棲]

貧血模型與領域架構模式

轉載：https://mabusyao.iteye.com/blog/467704

例子

我要舉的是一個銀行轉帳的例子，又是一個被用濫了的例子。但即使這個例子也不是自己想出來的，而是剽竊的<<POJOs in Action>>中的例子，原諒我可憐的想像力 。當錢從一個帳戶轉到另一個帳戶時，轉帳的金額不能超過第一個帳戶的存款餘額，餘額總數不能變，錢隻是從一個賬戶流向另一個帳戶，因此它們必須在一個事務內完成，每次事務成功完成都要記錄此次轉帳事務，這是所有的規則。

貧血模型

我們首先用貧血模型來實現。所謂貧血模型就是模型對象之間存在完整的關聯(可能存在多餘的關聯)，但是對象除了get和set方外外幾乎就沒有其它的方法，整個對象充當的就是一個數據容器，用C語言的話來說就是一個結構體，所有的業務方法都在一個無狀態的Service類中實現，Service類僅僅包含一些行為。這是JavaWeb程序采用的最常用開發模型，你可能采用的就是這種方法，雖然可能不知道它有個&ldquo;貧血模型&rdquo;的稱號，這要多虧Martin Flower(這個家夥慣會發明術語！)。

包結構

在討論具體的實現之前，我們先來看來貧血模型的包結構，以便對此有個大概的了解。

貧血模型的實現一般包括如下包：

• dao：負責持久化邏輯
• model：包含數據對象，是service操縱的對象
• service：放置所有的服務類，其中包含了所有的業務邏輯
• facade：提供對UI層訪問的入口

代碼實現

先看model包的兩個類，Account和TransferTransaction對象，分別代表帳戶和一次轉賬事務。由於它們不包含業務邏輯，就是一個普通的Java Bean，下麵的代碼省略了get和set方法。

這兩個類沒什麼可說的，它們就是一些數據容器。接下來看service包中TransferService接口和它的實現TransferServiceImpl。TransferService定義了轉賬服務的接口，TransferServiceImpl則提供了轉賬服務的實現。

Java代碼  

1. public interface TransferService {  
2.     TransferTransaction transfer(String fromAccountId, String toAccountId, BigDecimal amount)   
3.             throws AccountNotExistedException, AccountUnderflowException;  
4. }  

TransferServiceImpl類使用了AccountDAO和TranferTransactionDAO，它的transfer方法負責整個轉帳操作，它首先判斷轉帳的金額必須大於0，然後判斷fromAccountId和toAccountId是一個存在的Account的accountId，如果不存在拋AccountNotExsitedException。接著判斷轉帳的金額是否大於fromAccount的餘額，如果是則拋AccountUnderflowException。接著分別調用fromAccount和toAccount的setBalance來更新它們的餘額。最後保存到數據庫並記錄交易。TransferServiceImpl負責所有的業務邏輯，驗證是否超額提取並更新帳戶餘額。一切並不複雜，對於這個例子來說，貧血模型工作得非常好！這是因為這個例子相當簡單，業務邏輯也不複雜，一旦業務邏輯變得複雜，TransferServiceImpl就會膨脹。

優缺點

貧血模型的優點是很明顯的：

1. 被許多程序員所掌握，許多教材采用的是這種模型，對於初學者，這種模型很自然，甚至被很多人認為是java中最正統的模型。
2. 它非常簡單，對於並不複雜的業務(轉帳業務)，它工作得很好，開發起來非常迅速。它似乎也不需要對領域的充分了解，隻要給出要實現功能的每一個步驟，就能實現它。
3. 事務邊界相當清楚，一般來說service的每個方法都可以看成一個事務，因為通常Service的每個方法對應著一個用例。（在這個例子中我使用了facade作為事務邊界，後麵我要講這個是多餘的)

其缺點為也是很明顯的：

1. 所有的業務都在service中處理，當業越來越複雜時，service會變得越來越龐大，最終難以理解和維護。
2. 將所有的業務放在無狀態的service中實際上是一個過程化的設計，它在組織複雜的業務存在天然的劣勢，隨著業務的複雜，業務會在service中多個方法間重複。
3. 當添加一個新的UI時，很多業務邏輯得重新寫。例如，當要提供Web Service的接口時，原先為Web界麵提供的service就很難重用，導致重複的業務邏輯（在貧血模型的分層圖中可以看得更清楚），如何保持業務邏輯一致是很大的挑戰。
   

領域模型

接下來看看領域驅動模型，與貧血模型相反，領域模型要承擔關鍵業務邏輯，業務邏輯在多個領域對象之間分配，而Service隻是完成一些不適合放在模型中的業務邏輯，它是非常薄的一層，它指揮多個模型對象來完成業務功能。

包結構

領域模型的實現一般包含如下包：

• infrastructure: 代表基礎設施層，一般負責對象的持久化。
• domain：代表領域層。domain包中包括兩個子包，分別是model和service。model中包含模型對象，Repository（DAO)接口。它負責關鍵業務邏輯。service包為一係列的領域服務，之所以需要service，按照DDD的觀點，是因為領域中的某些概念本質是一些行為，並且不便放入某個模型對象中。比如轉帳操作，它是一個行為，並且它涉及三個對象，fromAccount，toAccount和TransferTransaction，將它放入任一個對象中都不好。
• application: 代表應用層，它的主要提供對UI層的統一訪問接口，並作為事務界限。

代碼實現

現在來看實現，照例先看model中的對象：

Java代碼  

1. public class Account {  
2.     private String accountId;  
3.     private BigDecimal balance;  
4.       
5.     private OverdraftPolicy overdraftPolicy = NoOverdraftPolicy.INSTANCE;  
6.       
7.     public Account() {}  
8.       
9.     public Account(String accountId, BigDecimal balance) {  
10.         Validate.notEmpty(accountId);  
11.         Validate.isTrue(balance == null || balance.compareTo(BigDecimal.ZERO) >= 0);  
12.           
13.         this.accountId = accountId;  
14.         this.balance = balance == null ? BigDecimal.ZERO : balance;  
15.     }  
16.       
17.     public String getAccountId() {  
18.         return accountId;  
19.     }  
20.   
21.     public BigDecimal getBalance() {  
22.         return balance;  
23.     }  
24.       
25.     public void debit(BigDecimal amount) throws AccountUnderflowException {  
26.         Validate.isTrue(amount.compareTo(BigDecimal.ZERO) > 0);  
27.           
28.         if (!overdraftPolicy.isAllowed(this, amount)) {  
29.             throw new AccountUnderflowException(this, amount);  
30.         }  
31.         balance = balance.subtract(amount);  
32.     }  
33.       
34.     public void credit(BigDecimal amount) {  
35.         Validate.isTrue(amount.compareTo(BigDecimal.ZERO) > 0);  
36.           
37.         balance = balance.add(amount);  
38.     }  
39.       
40. }  

與貧血模型的區別在於Account類中包含業務方法(credit,debit)，注意沒有set方法，對Account的更新是通過業務方法來更新的。由於“不允許從帳戶取出大於存款餘額的資金”是一條重要規則，將它放在一個單獨的接口OverdraftPolicy中，也提供了靈活性，當業務規則變化時，隻需要改變這個實現就可以了。

TransferServiceImpl類：

Java代碼  

1. public class TransferServiceImpl implements TransferService {  
2.     private AccountRepository accountRepository;  
3.     private TransferTransactionRepository transferTransactionRepository;  
4.       
5.     public TransferServiceImpl(AccountRepository accountRepository,   
6.             TransferTransactionRepository transferTransactionRepository) {  
7.         this.accountRepository = accountRepository;  
8.         this.transferTransactionRepository = transferTransactionRepository;  
9.     }  
10.       
11.     public TransferTransaction transfer(String fromAccountId, String toAccountId,  
12.             BigDecimal amount) throws AccountNotExistedException, AccountUnderflowException {  
13.         Account fromAccount = accountRepository.findAccount(fromAccountId);  
14.         if (fromAccount == null) throw new AccountNotExistedException(fromAccountId);  
15.         Account toAccount = accountRepository.findAccount(toAccountId);  
16.         if (toAccount == null) throw new AccountNotExistedException(toAccountId);  
17.   
18.         fromAccount.debit(amount);  
19.         toAccount.credit(amount);  
20.           
21.         accountRepository.updateAccount(fromAccount);   // 對Hibernate來說這不是必須的  
22.         accountRepository.updateAccount(toAccount);     // 對Hibernate來說這不是必須的  
23.         return transferTransactionRepository.create(fromAccountId, toAccountId, amount);  
24.     }  
25.       
26. }  

與貧血模型中的TransferServiceImpl相比，最主要的改變在於業務邏輯被移走了，由Account類來實現。對於這樣一個簡單的例子，領域模型沒有太多優勢，但是仍然可以看到代碼的實現要簡單一些。當業務變得複雜之後，領域模型的優勢就體現出來了。

優缺點

其優點是：

1. 領域模型采用OO設計，通過將職責分配到相應的模型對象或Service，可以很好的組織業務邏輯，當業務變得複雜時，領域模型顯出巨大的優勢。
2. 當需要多個UI接口時，領域模型可以重用，並且業務邏輯隻在領域層中出現，這使得很容易對多個UI接口保持業務邏輯的一致(從領域模型的分層圖可以看得更清楚)。
   

其缺點是：

1. 對程序員的要求較高，初學者對這種將職責分配到多個協作對象中的方式感到極不適應。
2. 領域驅動建模要求對領域模型完整而透徹的了解，隻給出一個用例的實現步驟是無法得到領域模型的，這需要和領域專家的充分討論。錯誤的領域模型對項目的危害非常之大，而實現一個好的領域模型非常困難。
3. 對於簡單的軟件，使用領域模型，顯得有些殺雞用牛刀了。

我的看法

這部分我將提出一些可能存在爭議的問題並提出自己的看法。

軟件分層

理解軟件分層、明晰每層的職責對於理解領域模型以及代碼實現是有好處的。軟件一般分為四層，分別為表示層，應用層，領域層和基礎設施層。軟件領域中另外一個著名的分層是TCP/IP分層，分為應用層,運輸層,網際層和網絡接口層。我發現它們之間存在對應關係，見下表：

對於TCP/IP來說，運輸層和網際層是最核心的，這也是TCP/IP名字的由來，就像領域層也是軟件最核心的一層。可以看出領域模型的包結構與軟件分層是一致的。在軟件分層中，表示層、領域層和基礎設施層都容易理解，難理解的是應用層，很容易和領域層中Service混淆。領域Service屬於領域層，它需要承擔部分業務概念，並且這個業務概念不易放入模型對象中。應用層服務不承擔任何業務邏輯和業務概念，它隻是調用領域層中的對象（服務和模型）來完成自己的功能。應用層為表示層提供接口，當UI接口改變一般也會導致應用層接口改變，也可能當UI接口很相似時應用層接口不用改變，但是領域層(包括領域服務)不能變動。例如一個應用同時提供Web接口和Web Service接口時，兩者的應用層接口一般不同，這是因為WebService的接口一般要粗一些。可以和TCP/IP的層模型進行類比，開發一個FTP程序和MSN聊天程序，它們的應用層不同，但是可以同樣利用TCP/IP協議，TCP/IP協議不用變。與軟件分層不同的是，當同樣開發一個FTP程序時，如果隻是UI接口不同，一個是命令行程序，一個是圖形界麵，應用層不用變（利用的都是FTP服務）。下圖給出領域模型中的分層：

Repository接口屬於領域層

可能有人會將Repository接口，相當於貧血模型中的DAO接口，歸於基礎設施層，畢竟在貧血模型中DAO是和它的實現放在一起。這就涉及Repository接口到底和誰比較密切？應該和domain層比較密切，因為Repository接口是由domain層來定義的。用TCP/IP來類比，網際層支持標準以太網、令牌環等網絡接口，支持接口是在網際層中定義的，沒有在網際層定義的網絡接口是不能被網際層訪問的。那麼為什麼在貧血模型中DAO的接口沒有放在model包中，這是因為貧血模型中DAO的接口是由service來定義的，但是為什麼DAO接口也沒有放在service包中，我無法解釋，按照我的觀點DAO接口放在service包中要更好一些，將DAO接口放在dao包或許有名稱上對應的考慮。對於領域模型，將Repository接口放入infrastructure包中會引入包的循環依賴，Repository依賴Domain，Domain依賴Repository。然而對於貧血模型，將DAO接口放入dao包中則不會引入包循環依賴，隻有service對DAO和model的依賴，而沒有反方向的依賴，這也導致service包很不穩定，service又正是放置業務邏輯的地方。JDepend這個工具可以檢測包的依賴關係。

貧血模型中Facade有何用？

我以前的做一個項目使用的就是貧血模型，使用了service和facade，當我們討論service和facade有什麼區別時，很少有人清楚，最終結果facade就是一個空殼，它除了將方法實現委托給相應的service方法，不做任何事，它們的接口中的方法都一樣。Facade應該是主要充當遠程訪問的門麵，這在EJB時代相當普遍，自從Rod Johson叫嚷withoutEJB之後，大家對EJB的熱情降了很多，對許多使用貧血模型的應用程序來說，facade是沒有必要的。貧血模型中的service在本質上屬於應用層的東西。當然如果確實需要提供遠程訪問，那麼遠程Facade(或許叫做RemoteService更好)也是很有用的，但是它仍然屬於應用層，隻不過在技術層麵上將它的實現委托給對應的Service。下圖是貧血模型的分層：

從上麵的分層可以看出貧血模型實際上相當於取消掉了領域層，因為領域層並沒有包含業務邏輯。

DAO到底有沒有必要？

貧血模型中的DAO或領域模型中的Repository到底有沒有必要？有人認為DAO或者說Repository是充血模型的大敵，對此我無論如何也不讚同。DAO或Repository是負責持久化邏輯的，如果取消掉DAO或Repository，將持久化邏輯直接寫入到model對象中，勢必造成model對象承擔不必要的職責。雖然現在的ORM框架已經做得很好了，持久化邏輯還是需要大量的代碼，持久化邏輯的摻入會使model中的業務邏輯變得模煳。允許去掉DAO的一個必要條件就是Java的的持久化框架必須足夠先進，持久化邏輯的引入不會幹擾業務邏輯，我認為這在很長一段時間內將無法做到。在rails中能夠將DAO去掉的原因就是rail中實現持久化邏輯的代碼很簡潔直觀，這也與ruby的表達能力強有關係。DAO的另外一個好處隔離數據庫，這可以支持多個數據庫，甚至可以支持文件存儲。基於DAO的這些優點，我認為，即使將來Java的持久化框架做得足夠優秀，使用DAO將持久化邏輯從業務邏輯中分離開來還是十分必要的，況且它們本身就應該分離。

結束語

在這篇文章裏，我使用了一個轉帳例子來描述領域模型和貧血模型的不同，實現代碼可以從附件中下載，我推薦你看下附件代碼，這會對領域模型和貧血模型有個更清楚的認識。我談到了軟件的分層，以及貧血模型和領域模型的實現又是怎樣對應到這些層上去的，最後是對DAO(或Repository)的討論。以上隻是我個人觀點，如有不同意見歡迎指出。

難過了，不要告訴別人，別人永遠都不可能明白在你的立場上的感受。難過了，靜靜的蹲下來抱著自己，讓眼淚盡情的灑落。難過了，拿著鏡子看看此刻的自己，讓真實浮現眼前。

最後更新：2017-04-03 05:40:06

  上一篇： 皮膚檢測算法三種，示例與代碼

  下一篇： Nodejs+Extjs+Mongodb開發第一天 Nodejs環境搭建