這里指的對象是從業務視角觀察的對象，如訂單，產品，合同，顧客都是一個典型的業務對象，我們關心的也是如何對訂單這個業務對象進行建模。

　　系統一般采用關系型數據庫來實現了數據的持久性機制，所以存在了面向對象的模型和關系模型間的轉換和映射問題。對于小型系統可以直接機械的將面向對象模型轉換為關系模型。但對于大型系統這個問題需要進一步考慮。

　　1.繼承關系

　　業務對象間也存在父對象和子對象的關系。對于繼承關系的映射關注的問題主要有兩個，一個是對于父對象是否要單獨映射相對應的數據表;另一個是對應不同類型的子對象是否都需要單獨建立相關的數據表。都單據映射數據表可以最大限度減少數據冗余，滿足范式的要求，但會帶來關系查詢和對象操作的復雜性。

　　企業業務對象應該在高層進行抽象，如該業務對象是否需要啟流程?該業務對象是否需要進行版本控制?通過這種抽象后應該剝離出流程和版本控制基對象，同時數據庫應該有相對應的數據表。這樣的好處就是系統中所有需要流程控制的業務對象以及對象的實例信息都可以在同一個數據表中快速檢索到，方面流程方面功能的系統實現。

　　2.關聯關系和引用關系

　　關聯關系在業務對象建模中最為常見，這也是最容易進行對象和關系映射的。

　　如訂單和訂單明細間是1對N的關聯關系,我們關注的訂單實體雖然是一個業務對象，但通過映射后會對應到后臺的兩張或多張數據庫表。

　　關聯關系必須相關的對象和數據項都是業務對象信息的一部分，隨業務對象存在而存在，關聯的明細對象一般都需要映射專門的數據表。

　　訂單頭需要引用顧客的信息，這是1:1的關系。在這里看到僅僅是訂單頭要引用顧客對象，而顧客對象是在其它地方進行的業務對象定義。這里在訂單對象上面也僅僅存儲關系，沒有任何信息會存儲在這個引用關系上面。所以這種引用關系的映射僅僅會是在訂單頭數據表增加相關的外鍵即可實現，而不需要單獨增加數據表。

　　3.關于代碼表和基礎數據

　　例如訂單類型，發運區域，付款方式等數據項，都需要通過代碼表的方式進行處理。所以代碼表應該是已經經過抽象的一個比較特殊的業務對象。通過代碼表的設計，可以解決大多數枚舉型數據項對數據的要求。

　　另外一些基礎數據是常說的不涉及到流程，權限和業務操作的數據對象。如單位信息對象，用戶信息對象。這些對象都是屬于系統的基礎信息存在，其本身不涉及到流程和業務處理，更多的是為其它業務對象提供服務。

　　在對象建模過程中，將業務對象和業務操作進一步分離，這樣業務對象可以作為實體和DTO來使用，便于相關的分布式計算和處理。業務操作也可以轉換為設計和實現中單獨的控制類，達到進一步的解藕。

　　某個業務對象建模過程中存在主體對象和關聯引用對象的概念。主體對象是操作中需要進行存儲和更新的對象，如對于訂單對象的訂單頭和訂單明細信息屬于主體對象。而顧客，商品等在訂單對象建模過程中就不屬于主體對象，僅僅是查詢和檢索時候需要附屬查看的相關信息。

原文轉自：http://www.anti-gravitydesign.com