Domain Model：Business Request的虛實之道與Business Action的設計模式     
     
Author：Anders小明
 
     在《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，很適合需要處理大量數據的情況。