这是我参与「第五届青训营」伴学笔记创作活动的第15天

前言
规则引擎概述。

规则引擎

• 低配版：没有配置界面，靠业务人员编写引擎规则DSL，一般存储在数据库或者文件中，这种没有彻底解放业务人员和开发人员的耦合，但是加快了业务代码的上线速度，以及很容易就能进行规则变更。
• 进阶版：这个一般是某种特定的系统，我们针对这种系统设置一些有针对性的页面，比如下面是某风控系统的截图，风控系统的规则引擎是相对来说比较简单的，只需要判断某些参数是否符合某些条件即可，然后返回固定的值即可。
• 完全版：在进阶版中规则引擎只是其中的一个部件，一般这种都很难复用于其他场景。但是一个完全版的规则引擎，追求的超高的通用性。

开发

在没有规则引擎的时代，有些逻辑比较复杂的业务，只有不断的增添if-else去满足我们这个复杂的业务场景，对于开发者来说还好，对于后面接手的同学一看到处都是if-else，体验过的同学就会知道，当然if-else可以通过一些模式去优化，比如使用策略模式，或者使用一些注解进行扩展点优化，这样的确可以解决一部分代码不清晰的问题，但是依然无法解决开发缓慢，需要上线等问题。 举个例子，在风控系统中，因为风控的逻辑在不断的发生一个改变，如果我们在代码中去写死，那么发生一个改变就改一下代码，上一下线，这明显是我们不能接受的。所以我们需要规则引擎去改变这个现状，通过高效可靠的方式去做这些业务规则的改变。

业务

以前的开发模式是业务人员提出业务规则叫开发人员做出相对应的业务开发，到底这个最后开发出来的业务规则是否和业务人员所提出来的是否一致，需要通过大量的测试去进行验证。而我们的开发人员理解业务很容易和业务人员的提出的业务有偏差，就会导致开发成本上升。有了规则引擎之后，我们就可以有下面几点提升：

• 业务人员独立配置业务规则，开发人员无需理解，让业务人员的规则和真正的实际情况一致。
• 增加业务的透明程度，业务人员配置了之后其他业务人员也能够知道，以前只能通过代码扣扣相传。
• 规则高效改动和上线，一般业务人员提出需求之后都是希望能尽快上线，但是之前都需要有代码开发，项目上线等环节，现在业务人员配置好了之后即配即用。
• 减少业务人员和开发人员的矛盾，开发人员通常会因为一些时间因素或者一些理解不到位导致业务人员的规则实现有偏差，最后业务同学会对开发同学产生一些小小的矛盾，这下完全业务配置解除开了之后，只要不断的升级规则引擎，业务规则就不会再对开发人员有依赖。

待整理后持续更新