Business Request的虚实之道

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。

（原文发在http://www.blogjava.net/AndersLin/archive/2006/09/19/70643.html，不过business action自己也没想好，就不贴在论坛上了。一直在等partech的Domain Model驱动一章，不知道什么时候能出来)

赫赫，抗议来了。
很不好意思，驱动这一章欠了这么久。主要是我希望通过一个实际的示例展现出来，但一直没有找到。
要说清楚Domain自然层次之间的驱动关系，不能太简单，如果仅仅只有业务交互或者编辑模式，层次的交互就体现不出来了。但也不能太复杂，那会吓跑所有的人。

具体到你的Business Request，我们做的，是会持久化的。也就是说把它当作DomainObject。当然除了Service对象，少数工厂对象和Helper对象外，所有的DomainObject,我们都会持久化。
比如：客户发起的受理单，最外层的受理Act创建好受理单对象后，会调用受理单的受理方法，然后受理单，去创建剩余的东西。最后当受理单被完全处理完后，完工Act，会查询出受理单，调用它的完工方法。

实际上，我们不光记录受理单，甚至我们还要记录驱动受理单的Act，也就是对受理单的瞬间动作。
目前俺正在干DomainObject自动日志的工作，思路就是持久化Act，并且持久化在Act中变动的其他DomainObject，这样就可以得到任何DomainObject的变化情况了。将采用一个Aspect来实现，该Aspect的部分切点可以同持久化的Aspect共享，所以我让他们继承定义了切点的共同抽象Aspect。自动日志额外的切点是需要知道当前DomainObject的变动是在哪个Act中发生的。

"具体到你的Business Request，我们做的，是会持久化的。也就是说把它当作DomainObject。当然除了Service对象，少数工厂对象和Helper对象外，所有的DomainObject,我们都会持久化。"

嗯嗯，电信行业需要吧，我估计（猜的）大部分的系统都没有记录request的，都是直接操作相应的domain objec，至于act更不会记录了!

保险的受理单也不用记录麽？

简单举例来说，客户订购商品，驱动入口是实现服务接口的服务方法，然后，创建一个订购Act，调用Act的run方法，Act代表本次订购业务交互，Act创建存在多次交互的业务交互，订购受理单，调用受理单的受理方法，订购受理单创建订购协议。这是最基本的业务。随后还会触发一个扩展，该受理单将启动一个工作流，来完成对订购受理单的处理，包括缴款，扣款，安装，完工等等活动。

简单来说，基本驱动就是小业务交互到大业务交互。还要根据概念依赖，处理扩展的问题。

目前没有，因为受理单扫描成影像文件了。



是的，交互应该这样设计的。
不过我以为这样描述还不够清析，我其实更期望类似模式那样的描述方式，我以为这也是你想表述的方式。
可惜自己做不到。所以就在这里等你的《驱动》一文呢！

这个比较奇怪了，如果受理单只是作为blob来处理，那里面的信息如何得到？
难道需要做的只是受理单管理？

比如客户要求索赔，就需要得到他当初签订协议的东西，然后按照条款和流程具体执行。

操作界面分左右两部分，左边是影像，右边是业务数据。

另外，I'm sorry


在认真看后，我觉的有点不同，实际上我更倾向于从一开始就由workflow全程控制。

那你的业务数据，持久化成啥了？



工作流难道不该看作是对正常业务的一个扩展么？没有工作流通过人工，也是可以完成业务的啊。
工作流不过是把这个自动化了。

没有工作流，业务可以独立存在，没有业务，工作流毫无意义，所以工作流-->业务，这是我的理解。

不是这样的。虽然受理单扫描成影像文件了，但是还需要录单员录入的，录入的过程中也是分许多步骤的，这些步骤一起形成了一个business request。
  有许多客户提出要求，在这个business request没有做完之前，不希望看到有提交，但是现在保单的录入都是分步提交的。所以一直没有能实现客户的要求，不知道两位有没有什么好的建议。

看不出分步提交有什么问题,客户为什么会一定要一次提交呢?
如果是不想看到非完整数据,可以设置一些标志位来过滤的。