记一次框架设计经验--规则引擎

前面讲数据质量监控的时候，楼下不少评论但愿能把规则引擎也讲一下，规则引擎是一个既复杂但又简单的系统，复杂的地方在于它要知足多种多样的业务需求，须要知道各个事实的既定结果，而后经过既定公式得到最终须要的结果。

在开讲以前咱们首先要了解几个名词：

 facts 事实，咱们实现的时候，会有一个事实库。用F表示。

patterns 模板，事实的一个模型，全部事实库中的事实都必须知足模板中的一个。用P表示。

conditions 条件,规则的组成部分。也必须知足模板库中的一条模板。用C表示。咱们能够这样理解facts、patterns、conditions之间的关系。Patterns是一个接口，conditions则是实现这个接口的类，而facts是这个类的实例。

rules 规则，由一到多个条件构成。通常用and或or链接conditions。用R表示。

actions 动做，激活一条rule执行的动做。

举个贷款的例子：一个在国企工做名下有一套房的35岁已婚男士去银行贷款买车。按照正常思惟，这我的工做稳定有持续的经济来源，在18周岁到56岁之间生活可以自理而且能持续还款，同时已婚表明有很大几率该客户责任心大，至少不会由于一些小挫折不还款，有担心，就有保证，若是是个人话，确定贷给他。

其实你们不可能根据一篇文章就会知道全部的规则引擎知识。从网上下了一张图，以下就是一个地址校验的规则，首先咱们去判断是否知足一个地址的长度或者说非空，才会走入下一个规则校验行政区和经纬度是否一致：

 

其实理论知识你们都知道很多了，上边的几个名词就是每条规则抽象出来的元件，还有就是rete算法是规则引擎比较经常使用的算法，你们能够了解一下。

我接下来说一下设计规则引擎时候注意的几个点：

1.通常来说规则都是有四则运算或者更复杂的数学计算组成，例如：非A即B，A且B为C

因此这些东西都是很容易抽象的，开发的时候确定要注意的。

2.你们都是程序员因此开发的时候仍是尽可能把作到可拓展，其实只要把架构的最小单元找对了，可拓展小菜一碟。。

写的很少，你们若是感兴趣我再接着写，实在是工做比较忙，只能找点下班时间写会