再論 Java 應(yīng)用中的“領(lǐng)域建模”

轉(zhuǎn)載請保留作者信息：

作者：88250

Blog： http:/blog.csdn.net/DL88250

MSN & Gmail & QQ：DL88250@gmail.com

最近又重新整理了一下項目中領(lǐng)域模型建模的思路。記得范凱（ robbin ） 在 2005 年時候總結(jié)的四種風格的“領(lǐng)域模型”及其一些變種相信大家的耳熟能詳了。以現(xiàn)在的觀點來看，不管其劃分是否合理，是否適合任何項目，討論都是有意義的。從 2004 年到 2008 年來領(lǐng)域模型的話題一直都是各個技術(shù)論壇、郵件列表必討論的話題之一，這里我只是想就‘領(lǐng)域模型建模’這個問題發(fā)表一下我的觀點，相信討論還會繼續(xù)下去，這才是本質(zhì)——演化。這里的觀點都是基于 Java 環(huán)境上的應(yīng)用展開的，其他語言環(huán)境另當別論。

相關(guān)術(shù)語與概念

首先，讓我們澄清一些相關(guān)術(shù)語與概念。很多時候發(fā)現(xiàn)大家討論問題前都沒有一個共同的基本假設(shè)作為前提，導(dǎo)致了問題越討論越混亂，引入的其他問題越來越多。這里，我先對本文涉及的幾個非常基本的概念做個統(tǒng)一的假設(shè)。

POJO（ Plain Old Java Object ）

POJO 是一個簡單的、常規(guī)的 Java 對象，它包含業(yè)務(wù)邏輯處理或持久化邏輯等，但不是 JavaBean、EntityBean 等，不具有任何特殊角色并且不繼承/不實現(xiàn)任何其它 Java 框架的類或接口（java.io.Serializable 除外）。例如下面這個類就是一個 POJO，注意業(yè)務(wù)邏輯方法：


/**
* A POJO user description.
* @author 88250
* @version 1.0.0.0, Jan 15, 2009
*/
public class User implements Serializable {

/**
* user name.
*/
private String name;

/**
* Default constructor.
*/
public User() {
}

/**
* User login business logic.
*/
public void login() {
// ....
}

/**
* Gets the name of this user.
* @return the value of name
*/
public String getName() {
return name;
}

/**
* Sets the name of this user.
* @param name new value of name
*/
public void setName(String name) {
this.name = name;
}
}

從 OO 的角度看，這是一個純粹的 Java 類，它擁有狀態(tài)與行為，這也就構(gòu)成了這個 User 類的職責。可惜現(xiàn)在 POJO 這個詞簡直是濫用啊，大家都認為只要描述的是一個領(lǐng)域 實體，一個純數(shù)據(jù)類就是 POJO 了 。

領(lǐng)域模型（ Domain Model ）

根據(jù) Martin 大叔的解釋，領(lǐng)域模型就是統(tǒng)一了 行為 與 數(shù)據(jù) 的 對象模型 。從 OO 的角度上看是沒有任何難點與疑問的，但是開始對具體項目著手進行 OO 設(shè)計的時候問題就很多了，后面將闡述一些在實施領(lǐng)域模型建模時“公認”的問題。再來看看 Wikipedia 上關(guān)于 領(lǐng)域模型的解釋 ，其中涉及到了“領(lǐng)域?qū)樱? Domain Layer ） ”這個概念，并且說明了 DDD 中的領(lǐng)域模型是領(lǐng)域?qū)拥囊粋€部分 。如下圖：

根據(jù) Wikipedia 上的解釋，領(lǐng)域?qū)优c 業(yè)務(wù)層 是同一個概念，這樣劃分的確是純粹的 DDD。不過，這與 JavaEE 規(guī)范中的分層理念有一點沖突，與 EJB 3 編程模型有著明顯的沖突。

各種風格（Style）的領(lǐng)域模型

這里的“風格”是按照 Martin 的觀點進行闡述的。在 以往的討論 中，有四種可行的模型：

• 失血模型
• 貧血模型
• 充血模型
• 脹血模型

這四種模型基本是 robbin 、 JavaEye 社區(qū)思考、討論的結(jié)果。但我認為還是按照 Martin 的提出的模型進行討論比較簡潔，有兩種可行的模型：

• 貧血的領(lǐng)域模型（Anemic Domain Model）
• 富領(lǐng)域模型（Rich Domain Model）

貧血的領(lǐng)域模型（ Anemic Domain Model ）

貧血的領(lǐng)域模型就是在領(lǐng)域?qū)ο笾? 只 包含了 accessors 方法，默認的構(gòu)造器，不包含任何邏輯處理。而邏輯處理放置于 xxxManager 中，使用事務(wù)腳本（ Transaction Script ， PoEAA ）進行操作。

富領(lǐng)域模型（ Rich Domain Model ）

富領(lǐng)域模型就是 DDD 中所描述的模型，完全的 OO Concerns 。

“公認”的問題

EJB 3 ＆ JPA

眾所周知，EJB 3 + JPA 的編程模型是典型的貧血模型，也是 JavaEE 所推廣的 最佳實踐 ，唯一正統(tǒng)的編程模型。 在這個模型中，EJBs 扮演了業(yè)務(wù)邏輯處理的角色，在分層設(shè)計中處于服務(wù)層 / 業(yè)務(wù)層。而 JPA entities 則扮演了典型的 純稚數(shù)據(jù)類 ，其行為完全由 EJBs 負責。這些也許與早先的 SSH 這樣一個 無狀態(tài) 框架組合那么深入人心密切相關(guān)吧。目前來說，Seam 框架 / WebBeans 規(guī)范是解決客戶端與服務(wù)端狀態(tài)問題的較好實現(xiàn)與規(guī)范。另外，Seam 中的 Entity 也是可以作為 Component 而 inject / outject 的，所以 Seam 有在嘗試 提供一個 DDD 的框架給開發(fā)者。

Domain Logic vs Business Logic

如果你是一個 DDD 的純粹擁護者，不存在區(qū)分領(lǐng)域邏輯與業(yè)務(wù)邏輯，統(tǒng)稱為領(lǐng)域邏輯。下面這個劃分領(lǐng)域邏輯與服務(wù)邏輯是針對類 EJB 3 + JPA 純粹用戶者的。
Domain 業(yè)務(wù)邏輯（Domain Logic）與 Service 業(yè)務(wù)邏輯（Business Logic）劃分的原則:

1. 根據(jù)是否依賴持久化邏輯劃分
   領(lǐng)域模型只包含不 依賴于持久化 的領(lǐng)域邏輯，而那些依賴持久化的領(lǐng)域邏輯應(yīng)該被分離到 Service 層
2. 使用 Rod Johnson 的"case by case"原則
   可重用度高的，和 domain object 狀態(tài)密切關(guān)聯(lián) 的放在 domain 中，可重用度低的，和 domain object 狀態(tài)沒有密切關(guān)聯(lián)的放在 Service 中

這樣，貌似是解決了 Java 應(yīng)用中使用“正統(tǒng)”方式（JavaEE 規(guī)范）實現(xiàn)領(lǐng)域驅(qū)動開發(fā)。但是，這樣不覺得過于復(fù)雜和畫蛇添足嗎？

結(jié)論

領(lǐng)域模型驅(qū)動的設(shè)計（DDD）是需要開發(fā)團隊在特定行業(yè)中 積累 到一定的時候才能真正做到的，這涉及到了企業(yè)（客戶）的核心價值實現(xiàn)與業(yè)務(wù)實現(xiàn) 重用 ，如果不是本著這個 最終目的 ，Java 下的 DDD 慎用。在建模你的 Java 項目時，一定要對項目的 Scope 做好分析，認真做好技術(shù)選型。一般來說，貧血模型（Anemic Domain Model）是最容易設(shè)計和實現(xiàn)的，也足夠滿足一般 Java Web 項目了。而領(lǐng)域模型（Rich Domain Model）是用在復(fù)雜 JavaEE 項目上的（例如實施 SOA 時），切勿殺雞用牛刀 :-)

參考列表

下面的文章是精華中的精華，有興趣、時間的朋友一定不要錯過 :-)

• Anemic Domain Model
• 總結(jié)一下最近關(guān)于domain object以及相關(guān)的討論
• 一個簡單例子：貧血模型or領(lǐng)域模型
• 對領(lǐng)域模型實現(xiàn)的總結(jié)性觀點
• 領(lǐng)域模型的價值與困境

再論 Java 應(yīng)用中的“領(lǐng)域建模”