本文放在javaeye可能未必合適。文章中中英文混用也是問題。
而且本文討論的模型比較適合交易類系統，對于ERP類未必合適。

Author :  Anders小明
原文: http://www.blogjava.net/AndersLin/archive/2006/10/09/74187.html

   在Domain Object的動靜之分中，其實我已經把業務對象分為三大類，不過在那一部分中沒有明確的提出。這三大類是Party，Product和Contract。
    Party
    包括Party對象和Role對象。
    Party代表業務發生對象的實體，而Role對象不僅僅是承擔的相應的責任，同時也是Party在具體業務中一個側面，因此除了責任還有保持一些實體業務關系的子集。例如：Party擁有多個Address和多個account，其中一個role只使用其中一個address和一個account。
    Role的分類有兩種。從性質來分，可以分為Individual和Organization；從業務來分Customer、Provider以及位于中間的Agency(以及Employee等)。 當然還要根據業務在進一步做細粒度的建模。
    不是所有的系統都需要Role的。在一些系統中對party和role的概念區分并不強烈，例如在一些普通的BBS或者CMS系統中，party和role一一對應，通常只設計role而忽略party，或者說直接把role對象party化。但在另一些系統中則不一樣，例如：在保險系統中，一個Party同時擁有多種Role是很普遍的；在eBay或者TaoBao等C2C系統中，一個Party既可以是Buyer也可以是Seller。
    Role和Role之間的relationship是一個很大的邏輯。例如：Employee是有上下級關系的；Agent是有introducer的。Relationship的實例化有兩種手段：一種是在role對象中建立，另一種利用獨立的一個relationship對象。
    和Party關聯的是另一大類對象Holding，不過Holding對象體系比較特殊，在金融行業中Holding是一個關鍵的對象體系，而在其它行業中，Holding則不那么重要，只是簡單的一個account記帳功能。
 
    Product
    Product對象比較麻煩，在金融行業看起來像另外一種contract。不過在B2C或C2C的電子商務中，Product則是代表現實世界中的商品。
    Product分為兩類：main和rider。Main product可以被單獨出售，而rider不能。這個實際上是一個固化的Package規則。
    還有一類Product比較特別，或者稱為Package Product，是幾種product打包一起，它擁有與product相同的屬性和行為。
    Product對象域包括兩部分邏輯：Product的Package規則，以及Product的計價邏輯。
    Product的Package規則。比如：rider product只能作為附屬品被售出；一些Rider Product只能和特定的main product綁定銷售；一些product不能同另一product同時銷售；一些product一次最多買5份。
    Product的計價邏輯包括兩個層次：Internal和External。Internal表現為根據自身條件判斷，如時間，折扣等級等；External則和contract中其它product相關，如：其它product總價超過一定價格就獲得額外折扣；或者同一個product份數超過3份就擁有一定的折扣。
    通常External建立在Internal之上，其關系有兩種，override和additional。Additional關系比較常見，通常是額外的折扣。
    計價邏輯的實現手段有兩種：一種是Rate Table，另一種是Formula Engine。對于Internal層次的來說，Rate Table比較常見。
    Product對象的這兩個邏輯都或多或少的與Contract相關聯。如同《分析模式》中描述的Quote那樣，這兩個邏輯將是獨立的Specification。
 
    Contract
    Contract是核心業務系統的關鍵。通常一個業務上的contract包括一系列的子contract。同時Contract又有多種類型。同product一樣，contract可以分為main contract和rider contract。典型的如Payment Agreement, Deliver Agreement都是rider contract。
    同Product一樣，Contract域包含兩個邏輯，contract的package規則和計價邏輯。
    不同類型的Contact包括不同的子contract。例如：保險系統中ILP和UP就包含了不同的子contract。
    Contract也擁有計價邏輯，而且通常和sale channel相關，如：通過網絡定購給予一定優惠。其與Product的計價邏輯通常是additional的關系，override非常罕見。
    同Product一樣，計價邏輯的實現手段也是Rate Table和Formula Engine。但對于Contract這一層次的來說，Formula Engine比較常見。
    一個contract不可避免的包含一個或多個Product，不過這里的Product和上面的Product不同，稱為contract product加以區別，表現為：雖然product在定義層面已經規定了大量的責任關系（操作范圍），當這些product被包含到contract中，通常會被參數化（子類型化），當然也有沒有被參數化的情況，可以看作一個特例。
 
    由于Contract是核心業務系統的關鍵，Main Contract關聯一個Life Cycle對象。如前所述，Life Cycle對象將是系統核心業務流程的驅動核心。另一個與Contract關聯的是Request對象。
    出于后期進行業務回查，以及數據挖掘的需要，除了Contract Product，還需要記錄所有相關Party在業務發生時的狀態，即所謂的歷史數據。 注意，這些數據并不是冗余數據。
        
    BTW：考慮金融市場下的，金融產品是虛擬的，它本身就是一個合同，包含了一系列的操作范圍--責任。注意在這個情況下：一個product包含了一系列的操作范圍--責任，從外部看，也呈現了一個完整的概念。而這與role的結構是很像的。雖然contract和product很自然的看成是include的關系，然而由于product本身是個完整的概念，使得我們可以反過來看，product修飾了contract。一個保單包含了不同的party，而保單中的保險產品修飾了保單--描述了不同party的責任關系。
安徽新華電腦學校專業職業規劃師為你提供更多幫助【在線咨詢】