前言
- 这是一篇翻译
- 最近在开发一些商业化的流程，之前一直是用状态机的思想去处理复杂的ToB流程, 这次突然想到了工作流，然后对于二者的区别有一些迷惑，找到了一篇不错的文章，感觉人工翻译一下比较好，送给有缘人，下面进入正文
简介
当公司决定实现一套系统来帮助他们管理商业流程的时候，他们的选择往往会介于工作流和状态机之间。尽管这两种系统的行为方式看起来非常相像，但他们还都是有一些列各自鲜明的功能特性。因此，有必要分析二者的优缺点，进而了解哪个系统更符合大多数公司的需要
做决策时应该考虑什么
当试图搞清楚到底要实现哪种系统时，非常有必要分析他们各自最主要的功能特性
灵活性
工作流引擎支持顺序模式当任务一个一个的执行时。下一步不会开始直到上一步执行完毕。比如，一份文件文件老板不会在律师签字前签字。因此，工作流引擎天然看起来就是僵硬的，确定的。状态机，恰恰相反，异步执行由于状态机中的每一步是由 时间/动作 触发的，所以他们不一定会按照严格的顺序执行。从这点来看，状态机时更加灵活的
然而，一旦你的公司有了新的商业需求，解决方案就会发生改变。想象这样一个状态机，它只有三个状态，提交申请，通过申请，驳回申请。当前，我们能看到三个独立的状态以及非常清晰的状态转换。然后你决定新增一些状态，比如，修改申请并征求反馈意见。在这个场景下，状态和状态转换的数量会大大增加。此外，每当添加新的状态，你都应该意识到的是你不可能独立的修改一个状态而不改变其余状态。结果就是，你会发现你并不是简单的增加了个新功能，而是在从头构建一个新的系统。因此，当你明白你的业务规则会随着时间的推移而改变（事实上这是不可避免的），工作流引擎是一个更好的选择
可理解性
状态机乍看之下很容易使用。开发者只需要回顾下公司的流程并画一个图，标识出一系列状态以及出发状态之间进行转换的事件。然而，状态机的主要问题是在实践中它仅仅适合处理一维的问题。它能够很好的服务哪些只有一些独立状态的项目，但是当系统更加复杂时，它就不适用了。一个典型的带有一系列顺序状态 CRM系统可能会造成很多问题。你将会不得不思考众多状态转换，诸如新线索的登记，项目的开始或取消。此外，这些状态中的每个状态都可以被分为不同的状态。例如，你可能想定义一个取消的原因，或通过哪个渠道找到一个新的线索（电子邮件活动、冷电话，等等）。当试图描绘这些状态中的每一种时，系统很快就变得无法管理。
工作流引擎起初似乎相当复杂，因为会部署额外的组件。然而，对于大型系统来说，它是最合适的解决方案。如果实施得当，其好处超过了明显的复杂性。工作流引擎似乎是业务流程管理的一个更好的模型。它经常被用于任务管理系统，能够快速地将任务分配给各种执行者。此外，工作流引擎通常有可靠的文档。一个新的开发者能够理解它，而不需要花几个小时去分析无数的代码。
Workflow engines seem to be quite complicated at first, since additional elements should be deployed. However, for larger systems it is the most appropriate solution. When implemented properly, benefits outweigh apparent complexity. Workflow engine seems to be a better model for business process management. It is often used for task management systems, being able to quickly allocate tasks to various executors. Moreover, workflow engines usually have solid documentations. A new developer will be able to understand it without spending hours analyzing endless lines of code.
