Domain Object ：基於業務行為的分析

Domain Object ：基於業務行為的分析
——Domain Object 的動靜之分，及其與 Business Process 的關係

Author：Anders小明
同步自：http://www.blogjava.net/AndersLin/archive/2006/08/25/65875.html
    
一、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的關係，都有助細粒度的分析系統的業務行為，做出合理的設計方案。
    （聽上去更像是口號宣傳）