Domain Model：业务流程的进一步分析

 在《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，很适合需要处理大量数据的情况。
    尤其要区别一下command pattern。Command是directly invoke，而以上三个pattern是indirectly invoke，隔着controller；同时command模式还要处理action的history问题，而以上三个模式不处理。