Domain Model：業務對象的進一步設計

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的責任關係。