Domain Model：业务对象的进一步设计

 在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的责任关系。