最近在javaEye上看到有關Domain Driving Model Design的激烈討論，讓我對DOMAIN MODEL的理解更深刻了不少，趁現在意猶未盡之際，結合我在項目中的實際經驗將討論中的一些結論摘錄并總結出來：

首先引用說明一下Domain Model 的定義：

Domain Model ： An object model of the domain that incorporates both behavior and data.

Domain Model 分兩種：

1  Simple Domain Model (Active Record)

它的特點是POJO和TABLE STRUCTURE一一對應，建模基于數據庫設計。Hibernate走的就是這個路子，說它貧血，意思就是指它只有data，沒有behavior。(但我們實際可以通過HBM文件的定義和映射，在PO中適當的加入一些基本的業務邏輯的。)

在這種模式下，POJO自己的CRUD操作都應該放在自己的類里面。其他復雜的業務邏輯會放到外面的Service layer。

2  Rich Domain Model (Data Mapper)

它的特點是POJO和TABLE STRUCTURE并不一一對應，建模天馬行空，完全取決于業務邏輯。domain object和table之間的mapping，由Data Mapper完成，domain object不用管數據表是何等結構，甚至不用管Data Mapper怎么操作。

1.識別某種業務行為的一個很確定的原則：

       domain logic只應該和這一個domain object的實例狀態(并非“持久”狀態)有關，而不應該和一批domain object的狀態有關.

進一步的說：主要看logic是否只和這個object(注：指自身)的狀態有關，如果只和這個object(注：指自身)有關，就是domain logic；如果logic是和一批domain object(注：指同類型的實體)的狀態有關，就不是domain logic，而是business logic。

2.Domain Model 與 Hibernate PO 的區別：

領域模型的代碼實現需要用一組互相協作的類來完成，每一個或者一組類承擔這個領域模型的某個特征。而Hibernate的實體類只不過是其中的一組類，它承擔的職責就是保持領域模型的狀態的。

3.基于Domain Model 分析與設計的方法規則：

應該由領域模型來驅動你的軟件內在規則，由需求驅動你的軟件外在交互.

最后，我想補充的是：根據目前的O/R Mapping技術，我們在實際項目開發中，能真正做到 富領域模型 還不現實(因為我們還要考慮諸如性能、目前O/R持久化特性等等問題)，更何況，我們的MODEL DATA最終需要被持久化，因此，我比較反對在DOMAIN MODEL 中直接通過任何方式做任何持久化操作，因為這會讓你所設計的MODEL無法獨立化，難以單元測試，并且與加入了一些外界無關的東西，這不符合對象的本質(對象本身是不能持久化的)。雖然我們做不到完整意義上的Domain Driving Model Development，但我們可以在項目實際開發中因為性能、結構簡化等等上面得到補償，這已經值得欣慰了。