面向变化的业务流程控制

新的需求是客户希望能够“提前启动一些工程阶段”——以前是客户定好了整个流程，全部按照既定的规则运行。

这个也能够理解，跟我们开发一样，真正进入开发阶段，并不完全是按照详细设计进行，也未必按照开发计划走，需求有变化的东西都要搁置，先开发已确定的东西，只管按里程碑交付就行了。

加入这个功能的目的是为了让“计划跟得上变化”，还好目前的流程引擎是基于有限状态机的，功能的扩展不会引起整个引擎的逻辑改变。

随着这个项目的深入，感觉客户是在不断的成长=_+前些天他们提出了可能的需求：为两个并行的下一步待办任务指定不同的待办人。

连同上一个需求，昨天想到一个比较可怕的问题：如果客户提出在每一个执行步骤都能够自定义一步或多步下一系列步骤怎么办？

PM同志说：那是不可能的，岂不是意味着我们的流程引擎失去了作用？

哈哈，对于现在有流程引擎，可能是失去了作用，但是“死流程引擎”上线后可能会马上失去对客户的作用才是真的。

流程引擎的一个重要功能是解释流程规则，目前大多数Workflow、BPM提供的建模工具和我设计的配置工具就是建立这样一个流程规则，然后布署，运行，对每一次运行进行一个规则持久化，以保证新规则不影响旧数据。如果需要更改，就得重新建流程规则，再布署。

纵观软件工程的发展，从面向对象、面向行为、面向方面、面向事件等编程思维，逐渐上升到面向服务、面向领域、面向流程的业务思维，其根本目的就是实现更灵活的业务改变，统一的口号都是“拥抱变化”。基于事件编程的好处是，把具体执行什么步骤，推迟到运行时刻。

流程引擎也需要做到在执行时刻能够重定义流程，如果权限和规则允许的话。这也就满足了在发生变化的时刻跟踪并进行改变。再变态一点是实现跨流程任务，由用户决定把哪一些自己的待办任务合并（Workflow Pattern中的Merge）到一起处理，举个形象的例子是去洗手间的同时把喝咖啡的杯子拿去洗了^O^而不是跑两趟~

本来这两天的任务是解决多任务不同处理人的问题，直接需要解决的是把处理人当作流程数据好，还是业务数据好？号称最灵活的OSWorkflow也没有解决这个问题……到现在都还没个定论，却噼哩叭啦引出这么多。