Domain Model：Business Request的虛實之道與Business Action的設計模式

Domain Model：Business Request的虛實之道與Business Action的設計模式     
     
Author：Anders小明
同步自：http://www.blogjava.net/AndersLin/archive/2006/09/19/70643.html
 
     在《Domain Object：基於業務行為的分析》一文中，我提出在high level的角度看，商務程序由三個模型構成：Business Request，Business Process以及Business Action。實際設計時，Business Request和Business Action將進步的細化。 
  
       Business Request的虛實之道 
      Business Request的概念，與http request是不同的。為避免誤解，特意加上Business一詞修飾。 
      所謂虛實是指是否將Business Request概念執行個體化。不做執行個體化的理由時處理簡單；執行個體化則有助於處理Business Transaction以及賬目模式。
一個業務上的Business Request可能包括多個Request Form，與核心業務對象對應，例如：線上訂單，就包括了購買物品及其數量和折扣，支付協議和發貨協議等。 
      對於沒有執行個體化Business Request的情況下，在實際業務操作時，對每一個form的操作都需要一個物理的transaction來支援。 
      這樣做的問題是，由於沒有記錄Business Request，直接操作業務對象，在做業務日誌時只能記錄操作前以及操作後的資訊（既“減肥前，減肥後”）；同時cross多個transaction，要支援查詢到一次Business Request所有操作的資訊，需要建立一個log index或者類似的手段，在業務開始時擷取註冊一個index，所有log操作中引用這個index，在業務結束後close該index。雖然如此，也帶來的是業務上做undo以及redo操作的不便。 
      但是如果執行個體化Business Request，就很容易處理這兩樣操作。建立一個Business Request，同時記錄所涉及的Request Form。這樣做的好處是：可以很容易的記錄一些額外的資訊；同時可以很容易的支援approve操作（既俗說的“管帳的不管錢，管錢的不管帳”）。不過目前大部分的系統都沒有處理Business Request執行個體化，不是所有的業務操作需要Approve，另外執行個體化的麻煩是Request Form會和Domain Object看起來一樣，已經處理了一個log對象，再處理一個request對象總是讓人多少心裡有點不爽；而頁面處理需要抽取出變化的properties。   

    Business Action的設計模式
    簡單的說，Business Action將被細化成action controller和concrete action。在這層級，action對於request的響應處理已知的有三種Pattern：
    Observer Pattern, Chain of responsibility Pattern以及Pipes and Filters Pattern，下面討論一下三者的區別：

name	Dispatch Mode	Actions Relation	Controller
Observer Pattern	request和action是one2many multicast deliver	各個action獨立工作 share the same input	Action register to Controller，Controller visit Action
Chain of Responsibility	request和action是one2one chained deliver	各個action獨立工作	controller poll actions
Pipes and Filters	request和action是one2many Piped deliver	各個action合作工作 share the same work data	controller iterate actions

    這三個pattern處理的各自不同的scenario.
    其中Pipes and Filters的alias是Data Flow Pattern，很適合需要處理大量資料的情況。