关于工作流引擎时限设计的一些建议

E8.net工作流系统设计同志写的博文，觉得有可以学习和借鉴之处，转帖如下，欢迎评论

个人的看法，对作者在文中提到的“契约书”程序设计的模式对我们的束缚很有体会，其实流程本身就是灵活的，不存在一个相对固定的规范和模式，我们做引擎设计的时候，更多的要考虑的是流程引擎对不同类型的用户自定义流程的“管理和控制”能力，同时又要考虑整个系统的层次结构和复杂度，在这几个问题上面来设计流程系统对我们的系统思维能力和把握系统整体关键点的能力要求就很高了，说句老实话，流程这个东西，越往后面搞，会越复杂，所以我们做设计的时候，不仅仅要考虑系统的灵活性，更要控制好流程系统的整体复杂度，因为系统如果设计得太复杂，不仅仅会导致编码的难度增大，也会使今后的升级和维护变得困难起来，使得整个系统在今后的发展过程中，路子越来越不好走。。。。所以我一直在犹豫是否要把前面设想的那个自适应构造引擎变成现实，原因我前面的博文已经说了，就是想控制流程系统的复杂度。。。。好，说了那么多废话，大家还是看看高手写的东西，甭听我瞎吹啦。。哈哈

===============================================================================

最近总有网友来咨询我和我的同事关于工作流引擎设计方面的一些思路，有一个很明显的感触，很多朋友在设计工作流引擎之前已经习惯了一种“契约式”编程设计的方式，也就是说在明确的需求和约束下去设计和开发。然而工作流引擎并不是一个能在明确需求和约束的情况下设计的算法。但无论怎样工作流引擎是需要为业务目标服务的，具体的业务流程如何，我们的算法和目标及准确的 计算是必然需要的。

   设计工作流引擎很多时候是需要去处理各种未知的、可能的、可能存在的、曾经有过的、各种版本的需求、只有进行了足够的抽 象和设计才能达到一个足够的灵活度和适应度。就拿处理时限来举例。
    就存在各种未知的、可能的、可能存在的、曾经有过的、各种版本的具体需求，无论哪种需求的可能，业务的目标不能受到影响 ，在工作流处理各种业务的时候，不能影响考核的准确性：
    1、时限分为 流程的处理时限、 环节的处理时限 ，两种时限上的关系错综复杂
  
    2、时限的单位 可能有按工作日计算 可能有按工分计算，也可能有按工时计算，也可能按自然分钟计算 和自然小时计算。
    3、具体业务流程中有可能会存在指定下一个环节的处理时限的需求
    4、流程暂停一段时间后需要重新计算处理时限
    5、具体的流程时限规定对具体业务上一些时限可能存在着某种影响
    6、流程暂停的时候对业务数据中的时限相关数据可能存在某种影响
    7、流程中的特殊权限可能对时限存在某种影响
    8、流程的暂停和恢复 可能对子流程的判断、时限存在着影响
    9、时限规定了之后，还可能有一个警告的设置
    10、预警的方式又可能有各种各样的
    11、流程时限计算好以后，实际流程运转过程中可能有调度、跳转、暂停等等特殊的行为，都不能影响对于超时未完成的事项的 计算
    。。。。。。

    设计一个工作流引擎 处理时限只是一个不特别重要的方面，还有很多方面要考虑的，比如环节的类型、各种条件路径的因素、各种特殊权限、特殊动作行为、跟业务的结合的方式、各种人员设置的方式、引擎跟业务数据的事务的完整性、引擎不能处理的时候业务上的方法和接口。。。。所有的情况都可能是未知的、可能的、可能存在的、曾经有过的、各种版本的。

    如果自己去设计工作流引擎，只有进行了足够的抽象和设计和长期优化积累才可能达到一个足够的灵活度、适应度和比较好的性能和稳定性，设计工作流引擎有时候在学习和理解流程引擎标准的前提下更需要去理解管理、理解各种管理流程的思路。也许应用一个成熟、稳定、性能好、有足够多成功实施经验的工作流引擎是一个更好的选择。