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

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

不是太理解！

楼主直接说客户,产品,订单更容易理解些,我觉得客户和产品都相对独立些,订单与他们必然存在耦合关系,请问楼主怎么考虑解耦的?

product和contract之间是什么关系？
谁依赖谁？

有点像ACORD模型，除非有推倒原有系统让业务流程适应标准的觉悟，要不然实施过程中会让人欲哭无泪。

客户太专有化，而且只是一种角色，对于一个在线书店来说，有三种角色，customer，provider和employee。
订单也太专有，通常一个订单是一个分析模式所说的合同夹，同样以在线书店为例，一个订单包括一个基本合同（买了什么东西，几份啊之类）和两个附加合同，一个货运合同（这里就有一个运费的概念）和一个付款合同。

解藕就只能靠接口或者抽象类来实现了，具体看项目的规模和复杂度。
通常是角色和产品是接口或者业务顶级类。订单不关联party，关联对应的角色。也关联产品。想springside所提供的例子。
复杂一点情况，可以独立定义不同的合同夹的子类（第二层级），关联或者耦合产品的子类（第二层级）等等类似的手法。

另外产品也是和合同存在约束关系的，以ebay的为例，卖家可以定义产品所支持的附加合同的，如只支持安付通和快递。
还有其他的，如某个产品需要一份额外的附加合同。

如果确实存在这样的双向关联关系，那么可以通过被我称为Product Line的领域对象来维护。这部分内容还没有放上我的blog。
而且一旦有这样的复杂性，通常就需要一个特别的visitor对象来展示某类产品（见分析模式产品一章），这个也将通过Product Line来维护。


如上所说，简单模型下，基本合同依赖产品就可以了。
关系复杂的情况下，谁依赖谁将变的复杂。

acord在保险业算是个标准吧，不过在内部的关联上我感觉不如IAA做的好！

兄弟有什么IAA实施的best practice吗？
最近有个项目是基于IAA模型裁减出来俄。
问某专家：“如何验证项目是否成功应用了IAA？” 答：“靠经验....”
这玩意真是IBM挣钱的好玩意阿，扔个概念给你，实施不成功首先可以推卸给业务流程不规范，业务流程规范的话还有数据模型不规范兜着，数据模型由专家看着裁减的话，还有实施过程不规范兜着...

best practice是没有的，还真是靠经验。
IBM靠它混饭吃的嘛！

color uml已经说得很简洁明白了.