Hen*_*rik 13 java grails drools jbpm activiti
我糊涂了.我正在为我的公司开发基于grails的内部工具.此工具中的一个组件是一个简单的问题跟踪器(帮助台功能).我有域对象,如问题,问题和NewFeature.每个域类都有不同的工作流程.
我最初的想法是在域对象中滚动我自己的状态机功能.然后我用Google搜索状态机引擎和工作流引擎.而现在我迷路了.
我想评论其他开发人员如何解决这个问题.你用Drools,Jbpm,Activiti吗？还是一些更简单的状态机引擎？
我一直在阅读Drools,Jbpm的一些文档.他们看起来很漂亮.但似乎我只需要这些库提供的一小部分功能.
我正在使用Grails,但它当然也很容易使用Java库.
ams*_*ams 15
工作流引擎的主要价值在于它可以通过某些工作流定义DSL自定义流.如果您不需要允许用户定义他们自己的任意工作流程,那么您最好自己构建自己的工作流程.
此外,工作流引擎通常使您能够定义长时间运行的业务事务和规则.例如,您可以拥有一个授权采购订单的工作流程,其中第一步是输入一些有关需要购买的信息,然后如果购买的价格低于100美元就可以获得规则,如果是100美元到2000美元之间的直线经理可以,如果它更多,然后将其发送给其他人进行审批......等等.随着金额的增加或公司的业务政策,这些类型的业务规则往往会发生变化.更改.因此,在这些场景中使用工作流引擎是有意义的.可以从工作流引擎中受益的复杂业务交易的其他好例子是提出保险索赔,授权贷款或抵押,评估客户的信用申请......等.这些业务交易往往经过多个人/部门并需要几个小时到几天或几周才能完成.
规则引擎适用于从应用程序中提取复杂但不断变化的规则.假设您是一家在线零售商,可以向美国,加拿大,英国,德国和法国的客户发货.您需要对在线商店销售的产品征税,但计算税收的规则因国家/地区和省内的省份而异.有些东西在一个省免税,但在其他省份没有.规则引擎非常适合这些类型的复杂业务规则,只要政府改变其税收政策,这些规则就会发生变化.规则引擎可以给你一个正确的答案你只需要去规则引擎说我想运行规则#10,这里是规则#10 x,y,z的输入,你得到一个答案.
规则引擎和工作流引擎之间的主要区别在于规则引擎不跟踪事务的状态,它应该是无状态的,仅对您提供的输入有效.工作流引擎是有状态的,它必须知道当前状态是工作流,并且必须将该状态保存到数据库.工作流引擎还等待来自外部源(例如人员或系统)的输入.
根据您对应用程序的描述,我将编写一些常规类来计算故障单的下一个状态,并确保该类具有良好的文档记录,并且可在几年内轻松更新.我认为规则引擎和工作流引擎对你的情况来说太过分了,你设置它们并使用它们所花费的时间要大得多,你需要在groovy中编写代码.如果随着时间的推移你发现你需要规则引擎和工作流引擎的复杂性,我会付出代价而不是现在,保持简单始终是最好的选择.
我不能同意上述AMS的回答,而且我想添加的另一件事是大多数情况下,使用工作流/规则引擎是过度和不必要的.KISS(保持简单和愚蠢)始终是最佳选择.和奥卡姆剃刀还表示,"实体不应该受到不必要乘以"
根据我在阿里巴巴的工作经验,大多数配备工作流程/规则引擎的应用程序都将维护工作变为噩梦,如果您使用简化的impl而不是盲目地选择工作流程/规则引擎,那么以后人们会对项目表示感谢.
那么,是否有指导说明何时使用工作流程？坦率地说,我不知道,但我所知道的是,当业务逻辑处于流程中时,我们绝对不应该使用工作流程.因为如果你愿意的话,每个商业逻辑都可以用流程图表示.
最后,我最正确的事情我去年做了一个重新设计是一个应用程序通过Groovy脚本,这使得整个系统更加直接,简单和快速更换Drools的.