基于工作流引擎的业务开发模式

很高兴能有回应，嘿嘿~~~
不知道以下判断对不对：
（1）对于任务项、活动实例和流程实例，系统中分别都有且只有一种状态机来描述这些对象的状态迁移；
（2）由于（1）的原因，相关的流程控制逻辑已经用程序语言编译到应用中了，系统并不支持让用户来自定义任务项、活动实例或者流程实例的状态机。

如果是这样，那么对于一般OA型应用是能够满足的，但在其它领域（比如工程设计领域）应用时可能会遇到灵活性不足的问题。举个例子：一个设计活动a有两个前驱活动a1和a2，当a1或者a2其中一个完成时，a可以提前开始执行而不必等到a1和a2同时完成，而且在只有部分输入的情况下，a也可以提交处理结果（比如预设计方案）给后继活动a3审核。此时，a3可以对于接收的预处理结果提出反馈意见让a修改其预提交结果，但是要求a3此时不能提交任何处理结果给下一环节（比如后续是制造活动）。这样的提前执行可以持续到a1和a2都完成后，a才能最终提交其正式处理结果给a3审核，而a3也只能在此基础上提交正式的审核结果给后续活动。在此期间，由于a和a3都不必等到前驱活动都完成而提前进行了处理而使得整个过程的执行周期缩短，但a提前执行时的状态在楼主的状态机中是无法得到反映的。

实际中，允许多种描述对象行为的状态机存在于系统中是必要的，毕竟，状态机不外乎就是为系统用户提供了一种定性地描述过程、活动和任务项等被监控对象执行进度的途径。IT人员要做的不是规定具体的一种或者几种状态机，相反，而是应该在系统中提供让用户能根据需要定制状态机并在多种状态机共存时仍能驱动过程正确执行的机制。

个人意见，仅供参考。嘿嘿~~~