本文中提到的<业务流程引擎>是指JBPM、Activiti之类。
最近被有人问到："为什么要用Activiti？ 我们直接把业务流程逻辑在代码里写进去不就可以了吗？"
我也不知怎么想的，随便回了句"至少得让人看到整个流程执行到哪个节点了吧。"
虽然没再说什么，但这个答案无疑是错的，我也在反省自己。
如果process engine仅仅是<生成流程图让用户看到自己启动的流程执行到哪个节点>的东西，也就是仅仅用于业务流程建模改善一下业务流程表述方式的话，任何人都可以做出"process engine"，然后给它添加一些小功能，完成它只是时间问题。
举个我自己的例子：
曾经为一个学校做过OA项目，项目中涉及到了一些审核流程的东西。
比如，购买一些教学用品需要申请提交用品类型和数量还有金额或者请假时也需要申请并需要通过上级审核。
它甚至有exclusive gateway，比如申请金额超过多少时或者请假时间超过多少时需要更上级的人员去审核(也就是不同的情况走不同的路线)。
但也就到此为止了，这个逻辑不会更复杂，也不会有变更(我会告诉你这个项目只是个形式？如果你跟你的上级单位说我们用那些经费实现了自动化一共花了￥￥￥...)。
于是我们就做了一个【伪·process engine】，设计数据表、写写代码、流程图用SVG(我喜欢这个东西)，好了，仅此而已。
现在我要严格要求一下，我说“业务流程逻辑不定期有变更，比如他的流程判断会多一个节点、流程判断时的参数值会变更等等，所以我们总不能写到代码里面吧。”
让我再追溯一番，曾经做一个项目的售前时的一段对话：
“这个金额的计算公式每个季度都会有所调整。”
“好的，那我们每个季度都帮您修改一下。”
“不，我希望您能给我们提供一个方式，让我们自己编辑。”
此时，我想到了ScriptEngine，你可以随便编辑，只要不发生异常。
但是你确定你能用script engine搞定业务流程图的建模问题？他能做到编辑？我能做到正确建模？也许我可以对script进行解释并建模，但我没这么神，我也不相信他有那么神（神甲方+神乙方 = =）。
我为什么这么执着于一个业务流程图？
这就像OO语言比汇编什么的更容易接受，因为他足够抽象。
用户不能编码，那为他们提供更抽象的东西就是了。那么，什么比script更抽象？画画呗，用户编辑的是流程图，看的也是流程图。
相对于某些复杂的编程语言，Java的语法就像我们平时说话一样通俗易懂；而相对于复杂的代码，图画自然更加简单。
既然解释script的叫script engine，那么解释流程图的就叫process engine。
终于，实际部署执行的流程可以通过抽象的流程图表达出来，也可以根据流程图去部署执行实际存在的流程。
这样就把业务流程的逻辑从代码里分离出来了，业务流程的自动化仅仅是通过简单的建模。
这帮我解决了“如何应对多变的业务逻辑”和“如何让用户自行编辑”两个问题，当然流程图也是一个难题。
所以，我找不到其他的替代品了，好好学习并加以利用吧。
