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

简介:

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

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

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

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

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

我的观点:

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

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

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

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

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

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

image

image

相关文章
|
3天前
|
前端开发 UED 开发者
开发同学如何理解业务?
本文深入探讨了理解业务的重要性及其对于软件开发流程的深远影响。
|
Java
规则引擎选型及应用
规则引擎具体执行可以分为接受数据输入,解释业务规则,根据业务规则做出业务决策几个过程。 使用规则引擎可以把复杂、冗余的业务规则同整个支撑系统分离开,做到架构的可复用移植。
24099 0
|
移动开发 前端开发 JavaScript
做前端技术方案选型的时候,你是怎么做决策的?
做前端技术方案选型的时候,你是怎么做决策的?
180 0
|
敏捷开发 消息中间件 测试技术
微服务面试必读:拆分、事务、设计的综合解析与实践指南
微服务的应用级别确实相对简单,但在实际开发中仍有一些技术难点需要解决。对于微服务组件的使用,确实不存在太大差距,但在设计和开发过程中需要积累经验。学习微服务的上手时间相对较短,可能只需一周到一个月的时间。然而,设计经验和技术难点是需要个人长期积累的,不能急于求成。因此,在使用和开发微服务时,更应该关注方案思考,展示自己对该领域的理解和见解。这样能够体现出你对问题的思考深度和解决方案的创新性。希望这次面试种子题目的解答能够帮助你应对面试官的问题!
132 0
|
消息中间件 SQL 关系型数据库
「要点解析」分布式高级商城业务:分布式事务,满足你的好奇心
数据库事务的几个特性:原子性(Atomicity)、一致性(Consistency)、隔离性或者独立性(Lsolation)和持久性(Durabilily),简称就是ACID原子性:一系列的操作整体不可拆分,要么同时成功,要么同时失败一致性:数据在事务的前后,业务整体一致转账:A:1000;B:1000;转 200;事务成功:A:800;B:1200隔离性:事务之间互相隔离持久性:一旦事务成功,数据一定会落盘在数据库
151 0
|
设计模式 安全 Java
基于设计模式改造短信网关服务实战篇(设计思想、方案呈现、源码)
基于设计模式改造短信网关服务实战篇(设计思想、方案呈现、源码)
378 0
|
自然语言处理 算法 数据挖掘
规则引擎设计 | 青训营笔记
规则引擎设计 | 青训营笔记
358 0
|
架构师 前端开发
上篇:技术架构的设计方法
技术思考本质还是结构化思考,所以常见的结构化思考方法也是适用的。这也是大家会看到很多技术架构师都会用一些方法论去分析问题的原因。但这里我不是重新去论述这些常见的技巧,而是分享从技术实战中得到的一些思考方法,为此我分为了技术架构设计的方法和技术 Leader 的思考方法两类。
1120 10
上篇:技术架构的设计方法
|
数据采集 存储 监控
谈谈对数据架构的几点认识
随着业务和数据环境的变化,组织的数据架构需要能够跟上这些变化的步伐。它需要具有响应能力,以便不仅确保组织继续有效运作,而且支持组织的整体战略方向。
谈谈对数据架构的几点认识
|
网络协议 中间件 程序员
分布式技术专题-服务架构设计-带你统一认识一下系统架构及分析和总结
分布式技术专题-服务架构设计-带你统一认识一下系统架构及分析和总结
356 0