Domain Object :基于业务行为的分析
——Domain Object 的动静之分,及其与 Business Process 的关系

Author:Anders小明
    
一、Domain Object的动静之分
1.1 动静的标准是什么?
在系统运行期间,被频繁建立和更新的称为“ 动态” ,而在较长的一段时间内保持稳定的称为 “ 静态” 。
 
1.2 考查Domain Object的动静将意义何在? 
     通常而言,“ 动态” 的Domain Object群通常代表了系统的核心业务对象。而 “ 静态” 的Domain Object则在业务上代表了系统的依存关系。 
    更进一步我们可以在“ 动态” Domain Object群中找到一个或几个代表了系统核心业务系统的核心。然而核心业务对象和综合业务对象还是有区别的,“ 动态” 的Domain Object中,最动态的不一定是综合业务的核心,在下面我们将举例说明。
    例如保险业务中,涉及的对象如下:
    Party(Customer以及各种Channel Role),Account,Product(险种),Policy(保单)等等,
    其中Policy对象是最频繁被操作的,而Party,Product两个则相对静态。
    在实际业务最常发生的操作也是关于保单的:新契约,保全,理赔,续保等等,很明显,Policy对象就是核心业务对象;Account变化将随保单业务发生;而Party和Product则给出了Policy对象的依存关系。
    然后保险业务的综合业务核心是Party更确切说是Customer。实际上几乎所有的金融服务的核心应该是CRM系统,保险公司(金融机构)是为客户提供全面的金融服务,帮助客户的管理金融资产也就是Holding,在其中最重要的是Account,至于Policy只是客户的一个资产(asset)而已;Party下的各种机构和Channel Role都为了支持公司提供金融服务的。
 
    SpringSide的Demo 例子BookStore 涉及的对象:
    Party(Customer, Provider 以及Deliverer), Book, Order 等.
    Order 是最强烈的动态特征的对象,它代表了BookStore 的核心业务。与保险系统做个类比就是:Order和Policy的概念一样,Book相当于Product,而Deliverer则是Channel Role。
    同样:BookStore的综合业务也是CRM,系统跟踪分析客户的阅读习惯和阅读兴趣以及支持习惯,为客户提供阅读服务。一如Amazon那样。
 
    又如DDD一书的提供的航运例子:Itinerary 是Shipping Model的核心业务对象。
   
二、 Domain Object与Business Process
弄清了Domain Object 的动静之分 ,就需要考虑Domain Object 与Business Process 关联关系。
从实际系统的观察来的看,几乎所有的系统的Business Proces( 核心业务流程和综合业务流程 )都是和“ 动态” 的核心业务对象的 LifeCycle 的Status 关联的。
 
2.1 先来观察一下核心业务流程: 
注意到核心流程的两个现象:
A. 几乎所有的业务操作都始于核心业务对象的建立,而止于该核心对象的死亡(停止),如保险的核心业务是是围绕policy的生命周期来做,新契约,保全,理赔,续保都是建立在policy上;BookStore则是在Order上;同时注意到不同的业务操作会影响了核心对象的LifeCycle的Status。
B. 由Customer的请求(客户向保险公司投保,或者要求加保,网上客户下购书订单,或网上支付)触发Business Process;Business Process又根据核心对象的LifeCycle Status和Request Context触发一系列的Business Action。
 
现在我们以保险业务为例来进行一个完整描述,观察一下涉及的几个概念:
Party(Customer, Channel Role ),Request,Business Action,Business Process 以及最后的 Policy 。
我们来看一下这里面的关系:
1. 首先一个由Customer发起一个投保请求(Request),其中这个投保请求由一个保险客户代表也就是agent(Channel Role)促成(即Request对象引用一个Agent Channel对象)
这个request将激活一个Business Process: 先完成一个投保单的基本信息录入操作,这个Action直接导致了一个Policy对象的建立,此时这个Policy对象的LifeCycle的status是Proposal;
3.接着工作流系统根据该保单的LifeCycle进入核保(underwriting)操作,而该操作促使Policy导向两个LifeCycle Status:Accept和Deny。
4.1 对于Accept的Policy,系统将触发一个通知,通知客户缴纳首期保费。
4.2 在客户缴费后,在系统内部产生一个系统的Request,该Request携带缴费信息,进入承保操作
4.3 承保操作查看缴费额度是否可以承保,如果可以则保单的LifeCycle状态变为inforce。
5.1 对于Deny的Policy,系统触发一个人工操作流程,由工作人员同客户联系调整投保信息如减少保额等
5.2 customer反馈一个request,如同意减少保额,系统进入一个修改Policy的操作,同时Policy的LifeCycle进入Proposal状态
5.3 系统进入3的流程
 
这里是一个简化的描述(另外系统不一定用WorkFlow),在实际业务操作中,还需要操作的对象包括了Party中的其它Role如Insurancer,Payee等等,每个Policy还需要指明具体的Product,以及Payment Agreement等等,当最核心的无疑是Policy对象,而Policy对象的LifeCycle Status又和Business Process有直接的联系。
 
对于BookStore也是如此,在客户下单后
1.Order的LifeCycle状态就是proposal,系统在此期间等待客户的两个请求:付款或者修改订单。
2.而在付款后,Order的LifeCycle状态就是Inforce,系统就通知工作人员开始配书。
3.配书结束后,Order的LifeCycle状态就是assembled
4.系统就要通知相关人员可以通过Deliverer发送订单。在此期间Order的LifeCycle状态为Deliver
5.系统收到Deliverer的货到通知,将Order的LifeCycle状态置为Complete。
 
这里要额外补充说明的是;
对于Request,每个Request必需记录下date,而Channel不一定。
对于Action,每个Action还可能保留一定的人工干预控制信息,也将同LifeCycle的Entry Data一起记录。
对于LifeCycle,每个LifeCycle Status的变化都可能会有独自的Entry Data(与Request Context有关,与Domain相关的)需要记录。
 
2.2 以上是对核心业务系统的讨论,现在要看的是所谓综合业务系统
对于综合业务系统,关注的是Party, Product两个对象系统。
很显然,客户的金融资产(保险系统)或者阅读习惯(BookStore)是系统关心的;product则是系统能为客户提供的服务或者产品;而Provider以及Channel Role包括Deliverer在内都是为服务提供支撑。
 
对于这些对象也就有自己的LifeCycle。虽然其LifeCycle的周期可能要长于Policy或者Order,但是其LifeCycle的状态却可能简单于Policy或者Order
 
Party和Product两个对象系统也有自己的Process,其Business Process的发起也是由request,由于相对于Policy和Order,两个系统相对 “ 静态 ” ,并由于其LifeCycle的简单性,加上这两类对象在实际业务中相比更带有正式授权特征。因此我用一个不同于request的概念Registration来代替。
 
其Process的过程和核心业务过程相差无几,不在复述。
目前对于综合业务系统还没有更多的想法就这样吧。
 
三、不算小结的小结
    无论系统建模还是系统重构,努力去观察了解Domain Object的动静之分,以及Domain Object与Business Process的关系,都有助细粒度的分析系统的业务行为,做出合理的设计方案。
    (听上去更像是口号宣传)