科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道基础软件Domain Model:业务对象的进一步设计

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

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

继续Domain Model的讨论,对业务对象做进一步设计,分为三个大类Party,Product和Contract。

作者:Anders小明 来源:CSDN 2008年3月22日

关键字: C C++ 业务对象 设计 Linux

  • 评论
  • 分享微博
  • 分享邮件
 在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的责任关系。  
    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章