最近总有网友来咨询我和我的同事关于工作流引擎设计方面的一些思路，有一个很明显的感触，很多朋友在设计工作流引擎之前 已经习惯了一种“契约式”编程设计的方式，也就是说在明确的需求和约束下去设计和开发。然而工作流引擎并不是一个能在明确需 求和约束的情况下设计的算法。但无论怎样工作流引擎是需要为业务目标服务的，具体的业务流程如何，我们的算法和目标及准确的 计算是必然需要的。
设计工作流引擎很多时候是需要去处理各种未知的、可能的、可能存在的、曾经有过的、各种版本的需求、只有进行了足够的抽 象和设计才能达到一个足够的灵活度和适应度。就拿处理时限来举例。
就存在各种未知的、可能的、可能存在的、曾经有过的、各种版本的具体需求，无论哪种需求的可能，业务的目标不能受到影响 ，在工作流处理各种业务的时候，不能影响考核的准确性：
1、时限分为 流程的处理时限、 环节的处理时限 ，两种时限上的关系错综复杂
2、时限的单位 可能有按工作日计算 可能有按工分计算，也可能有按工时计算，也可能按自然分钟计算 和自然小时计算。
3、具体业务流程中有可能会存在指定下一个环节的处理时限的需求
4、流程暂停一段时间后需要重新计算处理时限
5、具体的流程时限规定对具体业务上一些时限可能存在着某种影响
6、流程暂停的时候对业务数据中的时限相关数据可能存在某种影响
7、流程中的特殊权限可能对时限存在某种影响
8、流程的暂停和恢复 可能对子流程的判断、时限存在着影响
9、时限规定了之后，还可能有一个警告的设置
10、预警的方式又可能有各种各样的
11、流程时限计算好以后，实际流程运转过程中可能有调度、跳转、暂停等等特殊的行为，都不能影响对于超时未完成的事项的 计算
。。。。。。
设计一个工作流引擎 处理时限只是一个不特别重要的方面，还有很多方面要考虑的，比如环节的类型、各种条件路径的因素、 各种特殊权限、特殊动作行为、跟业务的结合的方式、各种人员设置的方式、引擎跟业务数据的事务的完整性、引擎不能处理的时候 业务上的方法和接口。。。。所有的情况都可能是未知的、可能的、可能存在的、曾经有过的、各种版本的。
如果自己去设计工作流引擎，只有进行了足够的抽象和设计和长期优化积累才可能达到一个足够的灵活度、适应度和比较好的性 能和稳定性，设计工作流引擎有时候在学习和理解流程引擎标准的前提下更需要去理解管理、理解各种管理流程的思路。也许应用一 个成熟、稳定、性能好、有足够多成功实施经验的工作流引擎是一个更好的选择。
（E8.Net）转载请注明出处