最近在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,但我們可以在項目實際開發中因為性能、結構簡化等等上面得到補償,這已經值得欣慰了。