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的关系，都有助细粒度的分析系统的业务行为，做出合理的设计方案。
（听上去更像是口号宣传）
