关于规则引擎的选型和疑惑思考

简介:

这是一个一些业务开发人员或者架构设计人员经常遇到的困惑:

1、给我推荐一个最简单、易用的规则引擎

1、运营人员觉得之前做的规则引擎不好用,是否可以做一个适合我们使用的规则引擎?不用看懂代码,直接界面表单提交操作。

2、我们的操作者是运营人员,大部分无技术背景,人员还有流动性,所以选型倾向选择可视化易编辑易理解的开源规则引擎。

能否推荐下选型,并说明优缺点

我的观点:

  • 1、你要的可视化易编辑易理解的开源规则引擎是不存在的。

通用的规则引擎只是把原来的java代码转化成了脚本来动态解析执行而已。本质上还是需要写代码,比如要写drools的表达式,如果你的运营人员不懂,并且培训无效那就没有办法了。

  • 2、但是基于规则引擎的业务系统可以做到配置人员无需了解代码。

这个过程首先需要开发人员总结、提炼出目前的N个业务类型,然后针对每个业务类型开发出运营人员需要配置的web界面。
这样当运营提交表单的时候,就可以通过后台程序自动拼装出脚本引擎可以解读的代码了。

  • 综上,如果只追求无需硬编码,并且配置人员懂得简单编码可以使用通用的规则引擎;如果还要追求配置界面的可读性,配置人员无需了解代码,开发人员就必须往前走一步,做每个业务类型的配置界面,然后再做一个界面到规则DSL语句的转化功能。

附录:一些半通用的规则配置截图:(取材自微信讨论群)

image

image

相关文章
|
Java
规则引擎选型及应用
规则引擎具体执行可以分为接受数据输入,解释业务规则,根据业务规则做出业务决策几个过程。 使用规则引擎可以把复杂、冗余的业务规则同整个支撑系统分离开,做到架构的可复用移植。
23954 0
|
10月前
|
移动开发 前端开发 JavaScript
做前端技术方案选型的时候,你是怎么做决策的?
做前端技术方案选型的时候,你是怎么做决策的?
136 0
|
4月前
|
存储 算法 Java
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)(一)
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)
81 1
|
4月前
|
存储 设计模式 监控
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)(二)
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)
75 0
|
4月前
|
Java API
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)(三)
【底层服务/编程功底系列】「手把手教学系列」带你打造一个属于自己的规则引擎服务,打破任何业务难题(逻辑模型和API设计)
73 0
|
消息中间件 SQL 关系型数据库
「要点解析」分布式高级商城业务:分布式事务,满足你的好奇心
数据库事务的几个特性:原子性(Atomicity)、一致性(Consistency)、隔离性或者独立性(Lsolation)和持久性(Durabilily),简称就是ACID原子性:一系列的操作整体不可拆分,要么同时成功,要么同时失败一致性:数据在事务的前后,业务整体一致转账:A:1000;B:1000;转 200;事务成功:A:800;B:1200隔离性:事务之间互相隔离持久性:一旦事务成功,数据一定会落盘在数据库
118 0
|
自然语言处理 JavaScript 前端开发
如何解决前端多语言选型和实现难题?
多语言(i18n)支持 是企业项目走向国际化的必经之路,也是前端工程师最佳实践的内容之一。不过,多语言框架众多,会带来一系列选型问题,相信大家在平时对项目进行多语言支持时,也往往会遇到如下几个问题:
1156 0
|
监控 应用服务中间件 测试技术
4种典型限流实践保障应用高可用|云效工程师指北
4种典型限流实践保障应用高可用,本文总结了一份AHAS限流实践指南,如果你的系统有被恶意用户攻击的风险,或者系统中某个应用出现异常可能会造成雪崩效应,那么这篇文章会对你有所帮助。
655 0
4种典型限流实践保障应用高可用|云效工程师指北
|
自然语言处理 算法 数据挖掘
规则引擎设计 | 青训营笔记
规则引擎设计 | 青训营笔记
311 0
化繁为简!阿里新产亿级流量系统设计核心原理高级笔记(终极版)
不管是初入职场的小菜鸟还是有一些工作年限的老司机,系统设计问题对他们来说都是一大困扰。前者主要是在于面试;面试官来一个如何从零到一设计一个完整的系统?大多数人都会直接懵了,因为系统设计覆盖面广,而网上资料又不能面面俱到,单独背背文章肯定是不行的;后者主要在于晋升;想要从程序员进阶到架构师,系统设计是必须要踏入的一道坎,他对你的技术广度跟深度都会有一定程度的考察。