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

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

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