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 |
其中Pipes and Filters的alias是Data Flow Pattern，很适合需要处理大量数据的情况。
