最神奇的事情之一就是 从事软件开发工作 是否具备在不同行业工作的能力——尤其是如果你是一名顾问. 您在一个行业工作时学到的大多数软件开发技能都可以直接转移到任何其他行业, 公司, 项目, 和利基市场.

我讲的是数据库设计， 设计模式, GUI布局、事件管理等. 当然，还有一些特定于某个特定行业、公司或项目的主题.

中小企业遇上IT，知识转移开始

这就是主题专家(SME)的用武之地. 中小型企业通常会参与到项目的设计阶段.

这家中小企业已经在这个行业工作了很长一段时间, 懂行话, 并理解代码背后的业务逻辑. 中小企业可能对软件开发有一定的了解, 但这并不是项目成功的必要条件.

对于很多项目, 除非软件开发人员非常了解业务逻辑, 完成一个成功的软件应用程序将是相对困难的. 根据项目的复杂性，需要花费在知识转移上的时间会有很大的不同.

假设采用了敏捷方法，并且在项目的整个开发阶段有一个或多个sme可用, 知识转移将在项目的所有阶段继续进行.

如果完全的知识转移是不可行的怎么办?

视行业和项目而定, 中小企业可能无法提供完整的知识转移.

例如, 想象一下，如果SME是一位有25年经验的医生, 你有6个月的时间来完成一个项目. Or, 想象SME是一个有40年经验的生物学家——这样的知识水平根本无法在软件开发项目的现实时间框架内转移.

但是如果知识领域是动态的呢?

通常，软件是根据时间或特性按照设定的时间表发布的. 然而，某些行业中的业务规则变化得更加频繁.

在很多情况下, 为了跟上行业的变化，经常发布软件可能是不可行的. 在这种情况下，具有在业务规则引擎中外部化业务规则的能力可能是有意义的. 软件项目能够承受变化的能力将对确保其最终的长期成功大有帮助.

规则引擎在何时何地发挥作用?

对于许多软件项目, 全面的知识转移是可行的, 而业务逻辑则用c#或Java等计算机语言编码.

然而, 有一部分项目需要对特定主题有大量的理解, 或者业务规则经常发生变化，因此让非程序员直接访问业务逻辑更有意义. This is the subject of this tutorial; with that in mind, let’s discuss Rules Engines in depth.

什么是业务规则引擎?

规则引擎是执行业务规则的工具. 业务规则由事实和条件语句组成. 任何出现在传统业务逻辑中的“if-然后”语句都有资格作为业务规则.

例如: if 员工连续病假5天以上，无医生证明的; 然后 它们需要被记录下来. If 一个商业伙伴已经超过6个月没有联系了，在此期间他们没有购买任何东西, 然后 也许是时候给他们发一封亲切的电子邮件了. If 患者体温高，视力有问题，并且有青光眼家族史， 然后 可能是时候要求做额外的核磁共振或其他检查了.

中小企业如何编写业务规则?

而不是期望中小企业 学习Java, C#, 或者其他编程语言, IT将为他或她创建一种迷你语言来表达他们的业务规则. 这些规则的构建块将由可以查询的事实组成. 按行业/实践领域划分的一些事实示例如下:

• 人力资源:工资，职位，经理，在公司工作年限
• 医疗:体温、血压、当前用药情况
• 财务:当前股票价格, 52周最高价/最低价, 市盈率, 下次收益发布的日期

本质上, 中小企业必须以一种精简的方式获得做出业务决策所需的信息.

这些规则是什么样的?

对于本规则引擎教程的其余部分, 我将使用Drools, 一个开源的基于Java的规则引擎, 可以在WWW上找到.drools.org是一个JBoss项目. 在Drools中，规则被编写为Java代码，并具有以下结构:

Import语句在这里:

rule“规则名称”
当
        	业务逻辑的“如果”部分在这里.
然后
        	业务逻辑的“然后”部分在这里.
结束

口水和工作记忆

流口水采用了一个叫做工作记忆的概念.

应用程序代码将负责将适当的事实加载到Working Memory中，以便sme可以编写查询这些事实的规则. 只有与应用程序业务逻辑相关的事实才应该加载到Working Memory中, 为了保持规则引擎以最高速度运行.

例如, 如果应用程序正在决定是否批准客户的贷款, 相关事实包括工资, 信用评分, 未偿贷款. 不相关的事实包括星期几或性别.

规则评估

流口水后的工作记忆已经装满了规则和事实, 根据规则的“然后”部分对规则进行评估. 如果" 然后 "部分的计算结果为true，则将执行规则的" 当 "部分.

通常, 所有的规则一次被评估, 尽管可以将规则分组在一起并按组进行评估. 规则的“然后”部分可以改变工作记忆的内容. 当发生这种情况时，Drools将重新计算所有规则，看看是否有规则现在计算为true. 如果是，它们的“当”部分将被执行.

规则计算的这种递归性质可能是好事，也可能是坏事——因此在创建规则时需要考虑到这种体系结构.

流口水规则的“如果”面

在流口水中，事实是用对象来表示的. 可以查询对象类型是否存在. 此外，还可以查询对象的属性.

下面是一些例子:

确定员工的收入是否超过10万美元.

Employee(salary > 100000)

确定患者的胆固醇水平是否大于200并且正在服用立普妥.

Patient(cholesterol > 200, medications.包含(“立普妥”))

确定股票价格是否在其年度高点的1%以内.

Stock(price >= (yearHigh * .99))

组合查询

在编写复杂的业务逻辑时, 业务规则可以通过使用布尔运算符AND来组合查询, OR, 和NOT和嵌套使用括号.

例如:

确定是否有收入低于75,000美元的经理或收入低于100,000美元的董事.

员工(位置.Equals(“Manager”),salary<75000) OR 员工(位置.Equals(“Directory”),salary<100000)

使用多种对象类型

到目前为止，所有示例都是基于单一对象类型，例如Employee或Patient. 但是，Drools允许基于多种对象类型进行查询.

例如:

确定客户的工资是否高于50,000美元并且没有申请破产.

Customer(salary>50000) AND not exists Bankruptcy()

规则中“然后”的一面

规则的“然后”部分决定了当规则的“当”部分至少有一个结果时将发生什么.

在Drools中，任何可以用Java编写的内容都可以写入规则的“然后”部分. 然而, 为了使规则更易于重用, 通常不放置任何I/O是一个好主意, 流量控制代码, 或规则内的一般执行代码.

作为一种选择，规则的“然后”部分可以用来修改工作记忆. 一个常见的做法是，当一个规则被评估为真时，将一个事实插入到工作记忆中.

例如:

规则”LoanApproved”
当
        	Customer(credit>700) && LoanOutstanding()
然后
        	插入(新LoanApproval ())
结束

我们如何知道一个规则何时被评估为真?

在触发所有规则之后，应用程序需要知道哪些规则被评估为真. If规则在对象求值为true时将其插入Working Memory, 可以编写代码来查询这些对象的工作内存.

在上面的例子中, 毕竟规矩已经被炒了, 可以进行查询以查看LoanApproval()对象是否在Working Memory中.

查询“GetLoanApproval”
        	结果:美元LoanApproval ()
结束

业务规则引擎如何与应用程序交互?

典型的应用程序包含业务逻辑， GUI， I/O和流控制代码.

例如，应用程序可以这样处理用户请求:

GUI ? 流控制 ? I/O ? 业务逻辑 ? I/O ? 流控制 ? GUI

嵌入规则引擎为这个过程增加了几个步骤:

GUI ? 流控制 ? I/O ? 创建规则引擎会话 ? 将事实添加到工作记忆中 ? 消防规则 ? 确定哪些规则的评估结果为true ? I/O ? 流控制 ? GUI

中小企业如何遵守规则?

创建、编辑和删除规则

为了让中小企业使用规则，他们需要一个用户友好的GUI. 有些业务规则引擎附带这样的接口.

例如，Drools附带了两个我认为用户友好的gui. 第一个类似于电子表格，允许中小企业创建规则，而无需编写任何实际代码. 第二个GUI允许创建更复杂的业务逻辑.

虽然这两种gui都有助于输入简单的条件, 当业务逻辑变得更加复杂时，它们将无法工作. 在这种情况下，您必须创建自己的自定义GUI.

SME自定义GUI的元素

为了中小企业的有效运作, 考虑创建一个具有以下功能的自定义GUI:

• 语法检查器-一个“检查语法”按钮可以调用Drools代码来检查可能的错误及其行号.
• 拖放——而不是要求SME记住对象和属性, 考虑为他们提供一个可以拖放的选择列表.
• Web接口——中小企业可以使用瘦客户端接口，而不需要考虑分销问题. 当GUI需要额外的功能和一般维护时，这将派上用场.
• Rule Tester——能够在不与整个应用程序交互的情况下测试单个规则，这将极大地提高SME的生产力. 允许SME GUI确定事实，然后触发单独的规则.

规则应该存储在哪里?

在Drools中，通常有两种存储规则的方法. Drools使用基于文件的规则开箱即用，这些规则通常具有 .drl扩展.

当规则数量较少时，这种方法效果很好. 随着规则数量的增长，您将需要使用数据库. 从数据库中存储和检索规则需要更多的工作, 但应该给你一个更易于管理的架构.

本规则引擎教程只涉及了Drools规则语言的很小一部分. 完整的描述请参考 官方参考文件.

使用规则引擎的决定不应该轻易做出. 而规则引擎将使您的应用程序更容易被中小企业扩展, 它的发展也将变得更加复杂, 测试和部署. 关于此主题的其他注意事项，您可能需要 查看以下指导方针.

现在我们可以继续向你展示一些更有趣的东西——一个简单的现实生活中的Drools的例子, 这是一个大多数Toptal博客读者应该都很熟悉的用例.

在现实生活中使用口水

Toptal, 高级软件开发人才的领先供应商, 目前，该公司使用“申请人跟踪”软件，让求职者经历招聘过程的各个阶段. 以下是该过程的简化可视化流程图:

目前, 决定申请人是否继续招聘流程的业务逻辑已经硬编码到软件中. 每当人力资源需要更改业务逻辑时，他们都必须让IT参与进来. 他们希望能够直接改变软件的运行方式.

申请人跟踪软件将被修改，以在招聘过程中的每个决策点运行HR提供的规则. HR将有一个“Candidate”对象，它将表示一个状态刚刚被初始条目修改过的求职者, 完成在线考试, 或者很多不同的因素. Candidate对象将具有表示经验、考试分数、面试分数等的字段.

下面的示例提供了一组简化的规则供您参考. 它还没有被部署，它只是一个简单的例子，由四个相互关联的规则组成:

• Submitted -> Testing
• Testing -> Interview
• Interview -> Project
• Project -> Hiring

Submitted -> Testing

基于当前客户需求, 人力资源部门希望编写一个规则，以确定候选人是否应该安排在线测试.

规则“测试时间表”
当
	美元的候选人: Candidate(status=='Submitted',yrsExperience >= 10, 
		skill(name=='Java', yrsExperience>=5) or Skill(name=='C#', yrsExperience>=5))
然后
	美元的候选人.setStatus(测试);
结束

Testing -> Interview

考生参加完在线考试后，需要对他们的成绩进行评估. HR也希望能够控制这一规则. 在线考试测试考生理解软件开发理论的能力, 解决问题, 和语法. 人力资源部想要决定什么样的分数组合将使候选人被考虑参加技术面试.

“安排面试时间”规则
当
	美元的候选人: Candidate(status=='Testing', testScore(theory>.8 && syntax>.6 && problemSolving>.8);
然后
	美元的候选人.setStatus(面试);
结束

Interview -> Project

技术面试将测试候选人讲述自己经验的能力, 回答解决问题的问题, 这将测试他们的交流能力. HR会写一个规则来决定技术面试的及格分数.

“项目进度”规则
当
	美元的候选人:候选人(状态= =“面试”, 	interviewScore(speakExperience>.9 && problemSolving>.8 && communication>.9 );
然后
	美元的候选人.setStatus(“项目”);
结束

Project -> Hiring

如果候选人通过了技术面试，他们将被分配一个离线编程项目. 他们将提交项目，并根据完整性、体系结构和GUI进行评判.

规则“招聘时间表”
当
	美元的候选人: Candidate(status=='Project', projectScore(completeness>.8 && architecture>.9 && gui>.7 );
然后
	美元的候选人.setStatus(招聘);
结束

如你所见, 即使是这个基本的例子也为人力资源提供了许多可能性, 它可以简化操作. 事实上，人力资源可以在不涉及IT的情况下修改规则，这将不可避免地节省时间并加快筛选过程.

由于规则可以随时更改，人力资源部门也会有更大的灵活性. 例如，HR可以通过设置不同的参数来扩展或限制选择过程.

如果有太多符合条件的候选人, 门槛可能在几分钟内提高, 从而减少了候选人的数量. 另外, 如果流程只产生很少或没有满足所有要求的候选项, 人力资源部门可以选择降低或取消一些标准, 将重点转移到更相关的技能上，直到有足够数量的候选人符合要求.