前言

一個項目中不一定都能用得上全部的分層規約，但十分有必要了解每一種的用法，便于去閱讀其他人的代碼。同樣的，雖然遵守規約寫代碼可能會略微拉低你寫代碼的速度（PS：多寫一些實體類），但越是規范化，模板化的東西，后期的維護成本和學習成本會越低。

《阿里巴巴Java開發規范》關于領域模型的部分介紹如下

分層領域模型規約:

DO(Data Object):此對象與數據庫表結構一一對應，通過 DAO 層向上傳輸數據源對象。

DTO(Data Transfer Object):數據傳輸對象，Service 或 Manager 向外傳輸的對象。

BO(Business Object):業務對象，由 Service 層輸出的封裝業務邏輯的對象。

AO(ApplicationObject):應用對象，在Web層與Service層之間抽象的復用對象模型， 極為貼近展示層，復用度不高。

VO(View Object):顯示層對象，通常是 Web 向模板渲染引擎層傳輸的對象。

Query:數據查詢對象，各層接收上層的查詢請求。注意超過 2 個參數的查詢封裝，禁止使用 Map 類來傳輸。

領域模型命名規約：

數據對象：xxxDO，xxx即為數據表名

數據傳輸對象：xxxDTO，xxx為業務領域相關的名稱。

展示對象：xxxVO，xxx一般為網頁名稱。

POJO：DO/DTO/BO/VO的統稱，禁止命名成xxxPOJO。

PO (persistant object )持久對象

可以看成是與數據庫中的表相映射的java對象。使用Hibernate來生成PO是不錯的選擇。

VO (value object) 值對象

通常用于業務層之間的數據傳遞，和PO一樣也是僅僅包含數據而已。但應是抽象出的業務對象,可以和表對應,也可以不,這根據業務的需要。

PO只能用在數據層，VO用在商業邏輯層和表示層。各層操作屬于該層自己的數據對象，這樣就可以降低各層之間的耦合，便于以后系統的維護和擴展。

DAO (Data Access Objects) 數據訪問對象接口

DAO是Data Access Object數據訪問接口，數據訪問：顧名思義就是與數據庫打交道。夾在業務邏輯與數據庫資源中間。J2EE開發人員使用數據訪問對象（DAO）設計模式把底層的數據訪問邏輯和高層的商務邏輯分開。實現DAO模式能夠更加專注于編寫數據訪問代碼。

DAO模式是標準的J2EE設計模式之一，開發人員使用這個模式把底層的數據訪問操作和上層的商務邏輯分開。一個典型的DAO實現有下列幾個組件：

一個DAO工廠類；

一個DAO接口；

一個實現DAO接口的具體類；

數據傳遞對象（有些時候叫做值對象），具體的DAO類包含了從特定的數據源訪問數據的邏輯。

BO (Business Object) 業務對象層

表示應用程序領域內“事物”的所有實體類。這些實體類駐留在服務器上，并利用服務類來協助完成它們的職責。

DTO (Data Transfer Object) 數據傳輸對象

主要用于遠程調用等需要大量傳輸對象的地方。比如我們一張表有100個字段，那么對應的PO就有100個屬性。但是我們界面上只要顯示10個字段，客戶端用WEB service來獲取數據，沒有必要把整個PO對象傳遞到客戶端，這時我們就可以用只有這10個屬性的DTO來傳遞結果到客戶端，這樣也不會暴露服務端表結構。到達客戶端以后，如果用這個對象來對應界面顯示，那此時它的身份就轉為VO。

POJO (Plain Old Java Objects) 簡單的Java對象

實際就是普通JavaBeans，使用POJO名稱是為了避免和EJB混淆起來，而且簡稱比較直接。其中有一些屬性及其getter、setter方法的類，有時可以作為value object或dto(Data Transform Object)來使用。

當然，如果你有一個簡單的運算屬性也是可以的,但不允許有業務方法，也不能攜帶有connection之類的方法。