(轉)一個簡單例子：貧血模型or領域模型
最近taowen同學連續發起了兩起關于貧血模型和領域模型的討論，引起了大家的廣泛熱烈的討論，但是討論(或者說是爭論)的結果到底怎樣，我想值得商榷。問題是大家對貧血模型和領域模型都有自己的看法，如果沒有對此達到概念上的共識，那么討論的結果應該可想而知，討論的收獲也是有的，至少知道了分歧的存在。為了使問題具有確定性，我想從一個簡單例子著手，用我對貧血模型和領域模型的概念來分別實現例子。至于我的理解對與否，大家可以做評判，至少有個可以評判的標準在這。
一個例子
我要舉的是一個銀行轉帳的例子，又是一個被用濫了的例子。但即使這個例子也不是自己想出來的，而是剽竊的<<POJOs in Action>>中的例子，原諒我可憐的想像力
。當錢從一個帳戶轉到另一個帳戶時，轉帳的金額不能超過第一個帳戶的存款余額，余額總數不能變，錢只是從一個賬戶流向另一個帳戶，因此它們必須在一個事務內完成，每次事務成功完成都要記錄此次轉帳事務，這是所有的規則。
貧血模型
我們首先用貧血模型來實現。所謂貧血模型就是模型對象之間存在完整的關聯(可能存在多余的關聯)，但是對象除了get和set方外外幾乎就沒有其它的方法，整個對象充當的就是一個數據容器，用C語言的話來說就是一個結構體，所有的業務方法都在一個無狀態的Service類中實現，Service類僅僅包含一些行為。這是Java Web程序采用的最常用開發模型，你可能采用的就是這種方法，雖然可能不知道它有個“貧血模型”的稱號，這要多虧Martin Flower(這個家伙慣會發明術語！)。
包結構
在討論具體的實現之前，我們先來看來貧血模型的包結構，以便對此有個大概的了解。
貧血模型的實現一般包括如下包：
dao：負責持久化邏輯
model：包含數據對象，是service操縱的對象
service：放置所有的服務類，其中包含了所有的業務邏輯
facade：提供對UI層訪問的入口
代碼實現
先看model包的兩個類，Account和TransferTransaction對象，分別代表帳戶和一次轉賬事務。由于它們不包含業務邏輯，就是一個普通的Java Bean，下面的代碼省略了get和set方法。
Java代碼
public class Account {
private String accountId;
private BigDecimal balance;
public Account() {}
public Account(String accountId, BigDecimal balance) {
this.accountId = accountId;
this.balance = balance;
}
// getter and setter ....
}Java代碼
public class TransferTransaction {
private Date timestamp;
private String fromAccountId;
private String toAccountId;
private BigDecimal amount;
public TransferTransaction() {}
public TransferTransaction(String fromAccountId, String toAccountId, BigDecimal amount, Date timestamp) {
this.fromAccountId = fromAccountId;
this.toAccountId = toAccountId;
this.amount = amount;
this.timestamp = timestamp;
}
// getter and setter ....
}
這兩個類沒什么可說的，它們就是一些數據容器。接下來看service包中TransferService接口和它的實現TransferServiceImpl。TransferService定義了轉賬服務的接口，TransferServiceImpl則提供了轉賬服務的實現。
Java代碼
public interface TransferService {
TransferTransaction transfer(String fromAccountId, String toAccountId, BigDecimal amount)
throws AccountNotExistedException, AccountUnderflowException;
}Java代碼
public class TransferServiceImpl implements TransferService {
private AccountDAO accountDAO;
private TransferTransactionDAO transferTransactionDAO;
public TransferServiceImpl(AccountDAO accountDAO,
TransferTransactionDAO transferTransactionDAO) {
this.accountDAO = accountDAO;
this.transferTransactionDAO = transferTransactionDAO;
}
public TransferTransaction transfer(String fromAccountId, String toAccountId,
BigDecimal amount) throws AccountNotExistedException, AccountUnderflowException {
Validate.isTrue(amount.compareTo(BigDecimal.ZERO) > 0);
Account fromAccount = accountDAO.findAccount(fromAccountId);
if (fromAccount == null) throw new AccountNotExistedException(fromAccountId);
if (fromAccount.getBalance().compareTo(amount) < 0) {
throw new AccountUnderflowException(fromAccount, amount);
}
Account toAccount = accountDAO.findAccount(toAccountId);
if (toAccount == null) throw new AccountNotExistedException(toAccountId);
fromAccount.setBalance(fromAccount.getBalance().subtract(amount));
toAccount.setBalance(toAccount.getBalance().add(amount));
accountDAO.updateAccount(fromAccount); // 對Hibernate來說這不是必須的
accountDAO.updateAccount(toAccount); // 對Hibernate來說這不是必須的
return transferTransactionDAO.create(fromAccountId, toAccountId, amount);
}
}
TransferServiceImpl類使用了AccountDAO和TranferTransactionDAO，它的transfer方法負責整個轉帳操作，它首先判斷轉帳的金額必須大于0，然后判斷fromAccountId和toAccountId是一個存在的Account的accountId，如果不存在拋AccountNotExsitedException。接著判斷轉帳的金額是否大于fromAccount的余額，如果是則拋AccountUnderflowException。接著分別調用fromAccount和toAccount的setBalance來更新它們的余額。最后保存到數據庫并記錄交易。TransferServiceImpl負責所有的業務邏輯，驗證是否超額提取并更新帳戶余額。一切并不復雜，對于這個例子來說，貧血模型工作得非常好！這是因為這個例子相當簡單，業務邏輯也不復雜，一旦業務邏輯變得復雜，TransferServiceImpl就會膨脹。
優缺點
貧血模型的優點是很明顯的：
被許多程序員所掌握，許多教材采用的是這種模型，對于初學者，這種模型很自然，甚至被很多人認為是java中最正統的模型。
它非常簡單，對于并不復雜的業務(轉帳業務)，它工作得很好，開發起來非常迅速。它似乎也不需要對領域的充分了解，只要給出要實現功能的每一個步驟，就能實現它。
事務邊界相當清楚，一般來說service的每個方法都可以看成一個事務，因為通常Service的每個方法對應著一個用例。（在這個例子中我使用了facade作為事務邊界，后面我要講這個是多余的)
其缺點為也是很明顯的：
所有的業務都在service中處理，當業越來越復雜時，service會變得越來越龐大，最終難以理解和維護。
將所有的業務放在無狀態的service中實際上是一個過程化的設計，它在組織復雜的業務存在天然的劣勢，隨著業務的復雜，業務會在service中多個方法間重復。
當添加一個新的UI時，很多業務邏輯得重新寫。例如，當要提供Web Service的接口時，原先為Web界面提供的service就很難重用，導致重復的業務邏輯（在貧血模型的分層圖中可以看得更清楚），如何保持業務邏輯一致是很大的挑戰。
領域模型
接下來看看領域驅動模型，與貧血模型相反，領域模型要承擔關鍵業務邏輯，業務邏輯在多個領域對象之間分配，而Service只是完成一些不適合放在模型中的業務邏輯，它是非常薄的一層，它指揮多個模型對象來完成業務功能。
包結構
領域模型的實現一般包含如下包：
infrastructure: 代表基礎設施層，一般負責對象的持久化。
domain：代表領域層。domain包中包括兩個子包，分別是model和service。model中包含模型對象，Repository（DAO)接口。它負責關鍵業務邏輯。service包為一系列的領域服務，之所以需要service，按照DDD的觀點，是因為領域中的某些概念本質是一些行為，并且不便放入某個模型對象中。比如轉帳操作，它是一個行為，并且它涉及三個對象，fromAccount，toAccount和TransferTransaction，將它放入任一個對象中都不好。
application: 代表應用層，它的主要提供對UI層的統一訪問接口，并作為事務界限。
代碼實現
現在來看實現，照例先看model中的對象：
Java代碼
public class Account {
private String accountId;
private BigDecimal balance;
private OverdraftPolicy overdraftPolicy = NoOverdraftPolicy.INSTANCE;
public Account() {}
public Account(String accountId, BigDecimal balance) {
Validate.notEmpty(accountId);
Validate.isTrue(balance == null || balance.compareTo(BigDecimal.ZERO) >= 0);
this.accountId = accountId;
this.balance = balance == null ? BigDecimal.ZERO : balance;
}
public String getAccountId() {
return accountId;
}
public BigDecimal getBalance() {
return balance;
}
public void debit(BigDecimal amount) throws AccountUnderflowException {
Validate.isTrue(amount.compareTo(BigDecimal.ZERO) > 0);
if (!overdraftPolicy.isAllowed(this, amount)) {
throw new AccountUnderflowException(this, amount);
}
balance = balance.subtract(amount);
}
public void credit(BigDecimal amount) {
Validate.isTrue(amount.compareTo(BigDecimal.ZERO) > 0);
balance = balance.add(amount);
}
}
與貧血模型的區別在于Account類中包含業務方法(credit,debit)，注意沒有set方法，對Account的更新是通過業務方法來更新的。由于“不允許從帳戶取出大于存款余額的資金”是一條重要規則，將它放在一個單獨的接口OverdraftPolicy中，也提供了靈活性，當業務規則變化時，只需要改變這個實現就可以了。
TransferServiceImpl類：
Java代碼
public class TransferServiceImpl implements TransferService {
private AccountRepository accountRepository;
private TransferTransactionRepository transferTransactionRepository;
public TransferServiceImpl(AccountRepository accountRepository,
TransferTransactionRepository transferTransactionRepository) {
this.accountRepository = accountRepository;
this.transferTransactionRepository = transferTransactionRepository;
}
public TransferTransaction transfer(String fromAccountId, String toAccountId,
BigDecimal amount) throws AccountNotExistedException, AccountUnderflowException {
Account fromAccount = accountRepository.findAccount(fromAccountId);
if (fromAccount == null) throw new AccountNotExistedException(fromAccountId);
Account toAccount = accountRepository.findAccount(toAccountId);
if (toAccount == null) throw new AccountNotExistedException(toAccountId);
fromAccount.debit(amount);
toAccount.credit(amount);
accountRepository.updateAccount(fromAccount); // 對Hibernate來說這不是必須的
accountRepository.updateAccount(toAccount); // 對Hibernate來說這不是必須的
return transferTransactionRepository.create(fromAccountId, toAccountId, amount);
}
}
與貧血模型中的TransferServiceImpl相比，最主要的改變在于業務邏輯被移走了，由Account類來實現。對于這樣一個簡單的例子，領域模型沒有太多優勢，但是仍然可以看到代碼的實現要簡單一些。當業務變得復雜之后，領域模型的優勢就體現出來了。
優缺點
其優點是：
領域模型采用OO設計，通過將職責分配到相應的模型對象或Service，可以很好的組織業務邏輯，當業務變得復雜時，領域模型顯出巨大的優勢。
當需要多個UI接口時，領域模型可以重用，并且業務邏輯只在領域層中出現，這使得很容易對多個UI接口保持業務邏輯的一致(從領域模型的分層圖可以看得更清楚)。
其缺點是：
對程序員的要求較高，初學者對這種將職責分配到多個協作對象中的方式感到極不適應。
領域驅動建模要求對領域模型完整而透徹的了解，只給出一個用例的實現步驟是無法得到領域模型的，這需要和領域專家的充分討論。錯誤的領域模型對項目的危害非常之大，而實現一個好的領域模型非常困難。
對于簡單的軟件，使用領域模型，顯得有些殺雞用牛刀了。
我的看法
這部分我將提出一些可能存在爭議的問題并提出自己的看法。
軟件分層
理解軟件分層、明晰每層的職責對于理解領域模型以及代碼實現是有好處的。軟件一般分為四層，分別為表示層，應用層，領域層和基礎設施層。軟件領域中另外一個著名的分層是TCP/IP分層，分為應用層,運輸層,網際層和網絡接口層。我發現它們之間存在對應關系，見下表：
| TCP/IP分層 | 軟件分層 | ||
| 表示層 | 負責向用戶顯示信息。 | ||
| 應用層 | 負責處理特定的應用程序細節。如FTP,SMTP等協議。 | 應用層 | 定義軟件可以完成的工作，指揮領域層的對象來解決問題。它不負責業務邏輯，是很薄的一層。 |
| 運輸層 | 兩臺主機上的應用程序提供端到端的通信。主要包括TCP,UDP協議。 | 領域層 | 負責業務邏輯，是業務軟件的核心。 |
| 網際層 | 處理分組在網絡中的活動，例如分組的選路。主要包括IP協議。 | ||
| 網絡接口層 | 操作系統中的設備驅動程序和計算機中對應的網絡接口卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理接口細節。 | 基礎設施層 | 為上層提供通用技術能力，如消息發送，數據持久化等。 |
對于TCP/IP來說，運輸層和網際層是最核心的，這也是TCP/IP名字的由來，就像領域層也是軟件最核心的一層。可以看出領域模型的包結構與軟件分層是一致的。在軟件分層中，表示層、領域層和基礎設施層都容易理解，難理解的是應用層，很容易和領域層中Service混淆。領域Service屬于領域層，它需要承擔部分業務概念，并且這個業務概念不易放入模型對象中。應用層服務不承擔任何業務邏輯和業務概念，它只是調用領域層中的對象（服務和模型）來完成自己的功能。應用層為表示層提供接口，當UI接口改變一般也會導致應用層接口改變，也可能當UI接口很相似時應用層接口不用改變，但是領域層(包括領域服務)不能變動。例如一個應用同時提供Web接口和Web Service接口時，兩者的應用層接口一般不同，這是因為Web Service的接口一般要粗一些。可以和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叫嚷without EJB之后，大家對EJB的熱情降了很多，對許多使用貧血模型的應用程序來說，facade是沒有必要的。貧血模型中的service在本質上屬于應用層的東西。當然如果確實需要提供遠程訪問，那么遠程Facade(或許叫做Remote Service更好)也是很有用的，但是它仍然屬于應用層，只不過在技術層面上將它的實現委托給對應的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)的討論。以上只是我個人觀點，如有不同意見歡迎指出。
netloser 
cknet