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