Domain Object ：基于業務行為的分析
——Domain Object 的動靜之分，及其與 Business Process 的關系
    
一、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的關系，都有助細粒度的分析系統的業務行為，做出合理的設計方案。
    （聽上去更像是口號宣傳）