Domain Object ：基于業(yè)務(wù)行為的分析
——Domain Object 的動(dòng)靜之分，及其與 Business Process 的關(guān)系
    
一、Domain Object的動(dòng)靜之分
1.1 動(dòng)靜的標(biāo)準(zhǔn)是什么？
在系統(tǒng)運(yùn)行期間，被頻繁建立和更新的稱為 “ 動(dòng)態(tài)” ，而在較長(zhǎng)的一段時(shí)間內(nèi)稱為 “ 靜態(tài)” 。
 
1.2 考查Domain Object的動(dòng)靜將意義何在？
    通常而言，“ 動(dòng)態(tài)” 的Domain Object群通常代表了系統(tǒng)的核心業(yè)務(wù)對(duì)象。而 “ 靜態(tài)” 的Domain Object則在業(yè)務(wù)上代表了系統(tǒng)的依存關(guān)系。
更進(jìn)一步我們可以在“ 動(dòng)態(tài)” Domain Object群中找到一個(gè)或幾個(gè)代表了系統(tǒng)核心業(yè)務(wù)系統(tǒng)的核心。然而核心業(yè)務(wù)對(duì)象和綜合業(yè)務(wù)對(duì)象還是有區(qū)別的，“ 動(dòng)態(tài)” 的Domain Object中，最動(dòng)態(tài)的不一定是綜合業(yè)務(wù)的核心，在下面我們將舉例說明。
    例如保險(xiǎn)業(yè)務(wù)中，涉及的對(duì)象如下：
    Party（Customer以及各種Channel Role），Account，Product（險(xiǎn)種），Policy（保單）等等，
    其中Policy對(duì)象是最頻繁被操作的，而Party，Product兩個(gè)則相對(duì)靜態(tài)。
    在實(shí)際業(yè)務(wù)最常發(fā)生的操作也是關(guān)于保單的：新契約，保全，理賠，續(xù)保等等，很明顯，Policy對(duì)象就是核心業(yè)務(wù)對(duì)象；Account變化將隨保單業(yè)務(wù)發(fā)生；而Party和Product則給出了Policy對(duì)象的依存關(guān)系。
    然后保險(xiǎn)業(yè)務(wù)的綜合業(yè)務(wù)核心是Party更確切說是Customer。實(shí)際上幾乎所有的金融服務(wù)的核心應(yīng)該是CRM系統(tǒng)，保險(xiǎn)公司（金融機(jī)構(gòu)）是為客戶提供全面的金融服務(wù)，幫助客戶的管理金融資產(chǎn)也就是Holding，在其中最重要的是Account，至于Policy只是客戶的一個(gè)資產(chǎn)（asset）而已；Party下的各種機(jī)構(gòu)和Channel Role都為了支持公司提供金融服務(wù)的。
 
    SpringSide的Demo例子BookStore 涉及的對(duì)象 ：
    Party(Customer, Provider 以及 Deliverer), Book, Order 等 .
    Order 是最強(qiáng)烈的動(dòng)態(tài)特征的對(duì)象，它代表了BookStore 的核心業(yè)務(wù)。與保險(xiǎn)系統(tǒng)做個(gè)類比就是：Order和Policy的概念一樣，Book相當(dāng)于Product，而Deliverer則是Channel Role。
    同樣：BookStore的綜合業(yè)務(wù)也是CRM，系統(tǒng)跟蹤分析客戶的閱讀習(xí)慣和閱讀興趣以及支持習(xí)慣，為客戶提供閱讀服務(wù)。一如Amazon那樣。
 
    又如DDD一書的提供的航運(yùn)例子：Itinerary 是Shipping Model的核心業(yè)務(wù)對(duì)象。
   
二、 Domain Object與Business Process
弄清了Domain Object 的動(dòng)靜之分 ，就需要考慮Domain Object 與Business Process 關(guān)聯(lián)關(guān)系。
從實(shí)際系統(tǒng)的觀察來的看 ， 幾乎所有的系統(tǒng)的Business Proces（ 核心業(yè)務(wù)流程和綜合業(yè)務(wù)流程 ）都是和“ 動(dòng)態(tài)” 的核心業(yè)務(wù)對(duì)象的 LifeCycle 的Status 關(guān)聯(lián)的。
 
2.1 先來觀察一下核心業(yè)務(wù)流程相關(guān)兩個(gè)現(xiàn)象的 ：
A. 幾乎所有的業(yè)務(wù)操作都始于核心業(yè)務(wù)對(duì)象的建立，而止于該核心對(duì)象的死亡（停止），如保險(xiǎn)的核心業(yè)務(wù)是是圍繞policy的生命周期來做，新契約，保全，理賠，續(xù)保都是建立在policy上；BookStore則是在Order上；同時(shí)注意到不同的業(yè)務(wù)操作會(huì)影響了核心對(duì)象的LifeCycle的Status。
B. 由Customer的請(qǐng)求（客戶向保險(xiǎn)公司投保，或者要求加保，網(wǎng)上客戶下購(gòu)書訂單，或網(wǎng)上支付）觸發(fā)Business Process；Business Process又根據(jù)核心對(duì)象的LifeCycle Status和Request Context觸發(fā)一系列的Business Action。
 
現(xiàn)在我們以保險(xiǎn)業(yè)務(wù)為例來進(jìn)行一個(gè)完整描述，觀察一下涉及的幾個(gè)概念：
Party(Customer, Channel Role ），Request，Business Action，Business Process 以及最后的 Policy 。
我們來看一下這里面的關(guān)系：
1. 首先一個(gè)由Customer發(fā)起一個(gè)投保請(qǐng)求（Request），其中這個(gè)投保請(qǐng)求由一個(gè)保險(xiǎn)客戶代表也就是agent（Channel Role）促成（即Request對(duì)象引用一個(gè)Agent Channel對(duì)象）
這個(gè)request將激活一個(gè)Business Process: 先完成一個(gè)投保單的基本信息錄入操作，這個(gè)Action直接導(dǎo)致了一個(gè)Policy對(duì)象的建立，此時(shí)這個(gè)Policy對(duì)象的LifeCycle的status是Proposal；
3.接著工作流系統(tǒng)根據(jù)該保單的LifeCycle進(jìn)入核保（underwriting）操作，而該操作促使Policy導(dǎo)向兩個(gè)LifeCycle Status：Accept和Deny。
4.1 對(duì)于Accept的Policy，系統(tǒng)將觸發(fā)一個(gè)通知，通知客戶繳納首期保費(fèi)。
4.2 在客戶繳費(fèi)后，在系統(tǒng)內(nèi)部產(chǎn)生一個(gè)系統(tǒng)的Request，該Request攜帶繳費(fèi)信息，進(jìn)入承保操作
4.3 承保操作查看繳費(fèi)額度是否可以承保，如果可以則保單的LifeCycle狀態(tài)變?yōu)閕nforce。
5.1 對(duì)于Deny的Policy，系統(tǒng)觸發(fā)一個(gè)人工操作流程，由工作人員同客戶聯(lián)系調(diào)整投保信息如減少保額等
5.2 customer反饋一個(gè)request，如同意減少保額，系統(tǒng)進(jìn)入一個(gè)修改Policy的操作，同時(shí)Policy的LifeCycle進(jìn)入Proposal狀態(tài)
5.3 系統(tǒng)進(jìn)入3的流程
 
這里是一個(gè)簡(jiǎn)化的描述（另外系統(tǒng)不一定用WorkFlow），在實(shí)際業(yè)務(wù)操作中，還需要操作的對(duì)象包括了Party中的其它Role如Insurancer，Payee等等，每個(gè)Policy還需要指明具體的Product，以及Payment Agreement等等，當(dāng)最核心的無(wú)疑是Policy對(duì)象，而Policy對(duì)象的LifeCycle Status又和Business Process有直接的聯(lián)系。
 
對(duì)于BookStore也是如此，在客戶下單后
1.Order的LifeCycle狀態(tài)就是proposal，系統(tǒng)在此期間等待客戶的兩個(gè)請(qǐng)求：付款或者修改訂單。
2.而在付款后，Order的LifeCycle狀態(tài)就是Inforce，系統(tǒng)就通知工作人員開始配書。
3.配書結(jié)束后，Order的LifeCycle狀態(tài)就是assembled
4.系統(tǒng)就要通知相關(guān)人員可以通過Deliverer發(fā)送訂單。在此期間Order的LifeCycle狀態(tài)為Deliver
5.系統(tǒng)收到Deliverer的貨到通知，將Order的LifeCycle狀態(tài)置為Complete。
 
這里要額外補(bǔ)充說明的是;
對(duì)于Request，每個(gè)Request必需記錄下date，而Channel不一定。
對(duì)于Action，每個(gè)Action還可能保留一定的人工干預(yù)控制信息，也將同LifeCycle的Entry Data一起記錄。
對(duì)于LifeCycle，每個(gè)LifeCycle Status的變化都可能會(huì)有獨(dú)自的Entry Data（與Request Context有關(guān)，與Domain相關(guān)的）需要記錄。
 
2.2 以上是對(duì)核心業(yè)務(wù)系統(tǒng)的討論，現(xiàn)在要看的是所謂綜合業(yè)務(wù)系統(tǒng) ：
對(duì)于綜合業(yè)務(wù)系統(tǒng)，關(guān)注的是Party, Product兩個(gè)對(duì)象系統(tǒng)。
很顯然，客戶的金融資產(chǎn)（保險(xiǎn)系統(tǒng)）或者閱讀習(xí)慣（BookStore）是系統(tǒng)關(guān)心的；product則是系統(tǒng)能為客戶提供的服務(wù)或者產(chǎn)品；而Provider以及Channel Role包括Deliverer在內(nèi)都是為服務(wù)提供支撐。
 
對(duì)于這些對(duì)象也就有自己的LifeCycle。雖然其LifeCycle的周期可能要長(zhǎng)于Policy或者Order，但是其LifeCycle的狀態(tài)卻可能簡(jiǎn)單于Policy或者Order
 
Party和Product兩個(gè)對(duì)象系統(tǒng)也有自己的Process，其Business Process的發(fā)起也是由request,由于相對(duì)于Policy和Order，兩個(gè)系統(tǒng)相對(duì) “ 靜態(tài) ” ，并由于其LifeCycle的簡(jiǎn)單性，加上這兩類對(duì)象在實(shí)際業(yè)務(wù)中相比更帶有正式授權(quán)特征。因此我用一個(gè)不同于request的概念Registration來代替。
 
其Process的過程和核心業(yè)務(wù)過程相差無(wú)幾，不在復(fù)述。
目前對(duì)于綜合業(yè)務(wù)系統(tǒng)還沒有更多的想法就這樣吧。
 
三、不算小結(jié)的小結(jié)
    無(wú)論系統(tǒng)建模還是系統(tǒng)重構(gòu)，努力去觀察了解Domain Object的動(dòng)靜之分，以及Domain Object與Business Process的關(guān)系，都有助細(xì)粒度的分析系統(tǒng)的業(yè)務(wù)行為，做出合理的設(shè)計(jì)方案。
    （聽上去更像是口號(hào)宣傳）