也许是流程做多了的缘故，所以看起程序开发来一切都是流程或者说都包含流程。个人认为大多数的企业应用（不包括特殊应用，例如文档库、信息资源库、BBS等等）不过是对数据以一定的样式展现（表单），以一定的逻辑对数据进行操作（业务规则），以及把这些处理数据的过程以一定的流程进行管理（流程）。上面三个方面分别对应着表单、业务规则和流程。程序开发中则对应于表单引擎、规则引擎和工作流引擎。而这些方面又可以统一到一个更大范畴的流程上来，所以这里有对流程驱动开发的设想。

先来看看具体的应用场景。

单表增删改查

这是最简单的情形，也没有流程，对这个情形不加讨论。但是这里会提到表单引擎，VB里的数据控件非常的易用，没有PO，没有DAO，也没有Service，直接与数据库字段进行绑定。我们的表单引擎也可以采用这种方式。

支持表单控件（输入框、文本框、下拉框等）的拖拽，将整个表单与数据库表绑定。

表单控件与数据库字段的绑定。

单表业务+流程

比上面的情况稍微复杂一点点，也就是要在业务里引入流程，其实这也是现在工作流引擎应用最多的地方，比如说政府OA里的收文、发文。

这里只需要将表单与流程进行绑定，表单引擎的处理方式不变，依然是直接与数据库表进行绑定。表单负责对数据库里的业务数据进行展现，工作流则负责推动这些数据在业务意义上状态的转换，互不影响，并在需要的时候在自动节点上对这些数据进行相应的业务处理。

关于表单权限。这个也是表单与工作流进行绑定时所必须考虑到的问题。其实只是需要在表单引擎里引入权限角色的概念，每个角色对应于一种权限，这种权限具体说来就是表单里每个字段的可见、可编辑等等。然后在人工节点定义时指定表单权限角色即可。这样也实现了流程与表单权限一定程度上的解耦。

其实还有一种更方便的方式，将表单直接与人工节点进行绑定，每个人工节点对应于不同的表单。

复杂一点，多表关联的情况

复杂一点的情况是业务往往是多表的关联。这需要对表单引擎做出扩展，让它可以根据关联字段对关联表做出查询，得到关联表的设计结构，继续映射。这让我想起了ORM，这里很有FRM的意思在里面。其实对于常用的关联查询往往有通用的组件可用，例如根据userid渲染出用户名，根据数据字典的id关联渲染出相应的值，oa里的正文、附件、印章等等。

流程跨越多个业务

流程需要跨越多个业务，一个典型的流程如下：

会议审批会涉及到两张业务表：会议室使用表，会议记录表。在会议申请和领导审批节点，最终用户打开的都是会议申请的表单，对应于会议记录表，对该表进行操作。但是流程运行到会议室管理员安排会议室的节点，该节点最终用户不仅需要看到会议申请的表单同时还要看到会议室使用情况的表单，如果有空闲的会议室，用户登记操作会议室使用表，然后通知申请者；如果没有空闲的会议室，则不用登记直接通知申请者。这个过程中跨越了两个业务，分别是会议室管理和会议管理。表单在各个节点也是不同的。

这其实对工作流引擎提出了比较高的要求。例如如果流程已经结束，会议得到批准，但申请者突然有事要改变会议时间怎么办？回退。这里的回退无疑就需要有业务的补偿，例如要删除会议室的相关记录。

应用集成

一个流程不仅会跨越多个业务，也会跨越多个系统。这里的应用场景很多，重要的是要去其他系统抓取数据和操作数据，仅仅靠数据库表对表单的映射满足不了需求。

对工作流引擎做出改进，与前面相比，需要由引擎来完成对其他系统服务的调用。这里一个很重要的载体就是XML。首先要定义交换数据所用的XML scheme，然后将这个XML scheme再与表单引擎做出映射。实际执行时，工作流的自动节点会在人工节点前调用其他系统的服务，按照XML scheme将数据转换为符合定义的XML，在紧接着的人工节点送给表单引擎，表单引擎渲染。修改数据也是同样的过程，表单引擎将处理后的数据以XML返回，工作流再次做出转换，调用服务的修改功能。

上面五种都是比较常见的应用场景，理想的情况下，开发方式应该是这样的：画出应用流程à定义流程表单à表单与数据库进行映射à对流程进行业务仿真à完成开发。问题是这样的：你的表单引擎是否足够强大？表单与后台是直接用SQL进行交互的，也就是Transaction Script模式，没有业务对象，对于复杂业务逻辑如何处理？如何使用规则引擎来解决业务逻辑的问题？权限如何以一种AOP的方式对数据操作进行横切？

呵呵，纯属个人YY。