使用工作流引擎、状态机引擎还是自己滚动？

Question

我很困惑。我正在为我的公司开发一个基于grails的内部工具。此工具中的一个组件是简单的问题跟踪程序（帮助台功能）。我有一些领域对象，比如Problem、Question和NewFeature。每个域类都有不同的工作流。

我最初的想法是在域对象中滚动我自己的状态机功能。然后我在google上搜索状态机引擎和工作流引擎。现在我迷路了。

我想听听其他开发者是如何解决这个问题的。你使用Drools、Jbpm、Activiti吗？或者更简单的状态机引擎？

我一直在为Drools、Jbpm阅读一些留档。它们看起来很不错。但我似乎只需要这些库提供的一小部分功能。

我使用Grails来实现这一点，但使用Java库当然也很容易。

Answer 1

“状态机”是常见的设计模式，那么drools实际上给了你什么呢？我个人认为drools是因为它的“查询语言”，这就是它的闪光点。你实际上有类似“从堆中查询对象的SQL”的东西。就像SQL给你“声明式”编程方式一样，当block描述何时以声明式方式开始状态转换时，drools。Drools默认被设计为全状态，状态就是插入到drools会话中的所有事实（POJO）。

让我向您推荐一个简单的用例。您必须为移动电话公司编写应用程序来管理电话呼叫：
如果呼叫者1正在呼叫被呼叫者2，而他此时并不“忙”，请连接他们
如果被叫人正忙，请继续呼叫7秒钟，如果被叫人在这段时间内取消了原来的呼叫，请立即连接他们
如果被叫方在7秒钟内没有断开连接，请删除带有消息“被叫方正忙”的呼叫方。

简单的三重if语句业务方法很快就变成了非常复杂且容易出错的技术任务。我想象5到10年前我见过很多后台计时器，或者一些更新的，比如ScheduledThreadPoolExecutor。如果在计划的延迟期间状态发生变化呢？你还会等到最后再重新计算条件吗？如果这种情况在您的应用程序中相对频繁，或者周期相对较长，您会在内存中保留“上下文”吗？您需要跟踪期货并取消它们或使用一些BlockingQueue。在这种情况下，需要为每个人维护队列，因为每个人都可能被某人呼叫。传统的OOP说“您应该将行为附加到您的域实体”。使用这种方法，您将开始用非常复杂的技术材料来混乱您的业务实体，即使您将使用一些模式来简化（封装）复杂性您的“状态机”开始在多个组件之间传播，如果您使用“分层样式”，则情况会更糟，因为您将开始为状态材料生成数据结构，如

Drools“自然”解决了这些问题，因为它使用了完全不同的方法。它跟踪工作内存中的所有对象（它跟踪规则条件），当时间到来时，drools只能说您的规则是否符合执行条件（rete算法可追溯到1979年）。如果状态发生变化，drools将以有效的方式重新评估每个规则的条件，并从“议程”（执行队列）中放置或删除相应的规则。所有插入到“工作记忆”中的对象都会形成一种“状态”，任何规则都可以依赖这种状态。您可以在这里找到上述用例的一些图表和测试以及drools规则的实际实现

使用正确的工具完成任务。如果需要在包含3-5个字段的状态对象的实体集合上循环，请不要在标题中添加“状态机”。如果您真的面临诸如“持续的行为改变”或系统中事件之间复杂的因果依赖关系之类的问题，那么drools是一个很好的、经过时间验证的开源rete算法实现。不要试图使用广告中的所有内容，深入了解细节，了解什么适合你的需要。

Answer 2

我非常同意AMS的回答，还有一点我想补充的是，对于大多数场景，使用工作流/规则引擎是多余和不必要的。KISS（保持简单和愚蠢）总是最好的选择。奥卡姆剃刀还说“实体不应该被不必要地乘以”

根据我在阿里巴巴的工作经验，大多数配备工作流/规则引擎的应用程序都将维护工作置于噩梦之中，如果您使用简化的impl而不是盲目选择工作流/规则引擎，那么以后来项目的人会很感激您。

那么，是否有指导原则告诉我们何时使用工作流？坦率地说，我不知道，但我知道的是，无论何时，只要业务逻辑处于流程中，我们都不应该使用工作流。因为如果您愿意，每个业务逻辑都可以在流程图中显示。

最后，我去年做的最正确的事情之一是重新设计一个应用程序，用groovy脚本代替Drools，这使整个系统更加简单、简单和快速。

Answer 3

工作流引擎的主要价值在于，它可以通过一些工作流定义DSL自定义流。如果您不需要允许用户定义自己的任意工作流，那么最好只构建自己的工作流。

此外，工作流引擎通常使您能够定义业务事务

规则引擎适用于从应用程序中提取复杂但不断变化的规则。假设您是一家在线零售商，向美国、加拿大、英国、德国和法国的客户发货。您需要对您在网上商店销售的产品征税，但计算税款的规则因国家和省而异。还有一些东西在一个省是免税的，但在其他省是不免税的。规则引擎非常适合这些类型的复杂业务规则，只要政府改变税收政策，这些规则就会发生变化。规则引擎可以以正确的方式为您提供答案，您只需转到规则引擎，说我想运行规则#10，这里是规则#10的输入x、y、z，然后您就会得到答案。

规则引擎和工作流引擎之间的主要区别在于，规则引擎不跟踪事务的状态，它应该是无状态的，只处理您提供的输入。工作流引擎是状态完整的，它必须知道工作流的当前状态，并且必须将该状态保存到数据库中。工作流引擎还等待来自外部源（如人员或系统）的输入。

根据您对应用程序的描述，我只需编写一些groovy类来计算票证的下一个状态，并确保该类有良好的文档记录，并且在几年内易于更新。我认为规则引擎和工作流引擎对于您的情况来说是过度的，设置和使用它们所需的时间要比在groovy中编写代码所需的时间多得多。如果随着时间的推移，你发现你需要规则引擎和工作流引擎的复杂性，我会在那时而不是现在付出代价，保持简单永远是最好的选择。