領域模型驅動（
Domain Driven Design
），很熱的名詞。
Openfans
，不太熱的網站。今天俺就借著很熱的
ddd
，給不太熱的
openfans
再造點勢。
Openfans
就不多介紹了，網站用
spring+hibernate
為核心的一堆開源軟件構建。有了
spring
的
IOC
和
hibernate
的
ORM
，打著
ddd
的旗號也就名正言順了很多。先聲明其實俺對
ddd
的理解也多是道聽途說，沒有什么系統的學習過，倒是和
Joe
阿牛討論過幾次，頗有受益，他對這個理解還是很深刻的。
言歸正傳，就講
openfans
現在經
ddd
思想改造過的模型。整體上看還是普通的三層架構體系：展現層、業務層、持久層。展現層用
spring mvc
，力圖做到只是展示相關，避免出現業務邏輯。再具體細分，就是
jsp
頁面只有展示邏輯，主要使用
jstl
完成顯示功能。
Controller
負責從頁面獲得參數、把數據傳回頁面、控制頁面流傳和調用業務層的接口。持久層使用
hibernate
，在設計上我不是按
dao
方式為每個對象建立相應的
dao
，也不是
ddd
推薦的每個
domain
一個
repository
，而是分成了
Persistence
和
Fetcher2
個接口。
Persistence
處理持久相關如
save
和
remove
方法，
Fetcher
則處理
get
相關。這樣分的原因也很簡單，
persistence
是很穩固的，對象都可以共用一個接口如
save
（
Object
），而
fetcher
就千變萬化，需要分頁、排序等接口。
這樣設計是與業務層架構相關的。我采用的是
domain
對象（簡稱
DO
）
+
一層薄薄
fa?ade
的方式。
DO
處理自身的邏輯，包括持久功能。本身
DO
是沒有持久能力的，需要依靠注入的
persistence
接口，這里就體現按
Persistence
和
Fetcher
分開的一個好處，
persistence
所有
DO
可以共用一個，給編程帶來了方便。
Openfans
中采用的是
DO
繼承一個抽象
PersistentObject
類的方式，這樣
DO
方便的獲得了注入的能力和持久的能力。這樣做有何優缺點還需要做些討論，為了方便我也就先這么用。
PersistentObject
代碼如下：
public abstract class PersistentObject implements NeedPersist {
?????? private Persistence persistence;
?
?????? public void save() {
????????????? persistence.save(this);
?
?????? }
?
?????? public void remove() {
????????????? persistence.remove(this);
?????? }
?
?????? public void setPersistence(Persistence persistence) {
????????????? this.persistence = persistence;
?????? }
?
?????? public Persistence getPersistence() {
????????????? return persistence;
?????? }
}
這樣
DO
只需要注入
persistence
就獲得了持久的能力，而且可以把這種能力往下傳遞。
DO
獲得了持久能力，就有點接近富血模型的想法了，他能夠處理一些業務，做持久然后調用引用對象的業務和持久方法
(
從另外的角度看持久與業務其實是分不開的
)
。這樣把業務封裝在了領域本身，更適于用領域對象出發的方式去思考問題。領域層的
fa?ade
主要是為了
Transaction
管理和隱藏
DO
接口。這樣
DO
的業務方法都可以設置成
friendly
，僅相互間可見。
Fa?ade
就放在
domain
包中，它負責給
DO
注入
persistence bean
，調用
DO
的接口，提供給
controller
一個
use case
級別的接口，同時它也代理
fetcher
的接口。
有了這個架構，實現起來也不復雜，要配置的
bean
很少（現在還沒有使用
spring 2.0
將
DO
配置在容器中）。設計就從
DO
出發，明確它的屬性和方法，讓
hibernate
自己生成數據庫表。
??????
這樣設計也算是一次嘗試吧，其中肯定有很多考慮不周的地方，需要不斷的討論和改進。