如何使用 Java lambda 语法和外部规则引擎开发定制应用程序

作者|SohamSengupta、SrijeebRoy
译者|陈亮芬
策划|丁晓昀
复杂的企业应用程序通常有着不同的业务逻辑 。 这些业务逻辑中的前置条件和后续系统动作(也就是我们所说的规则)总是变化的 。 而且 , 比起技术和编程 , 我们这里所说的规则更需要特定领域的知识介入 。 我们在实现这些规则时不应老想着靠代码 , 反而应该驻留在代码库之外 , 由具有核心领域专业知识的人去进行规则编写(他们只需要具备极少的技术及编程知识) 。 有一种特定类型的软件工具 , 也就是规则引擎可以帮助解决难以确定的业务规则需求 。 领域专家们并不需要擅长编码和技术 , 就像企业的品牌和营销团队不需要知道企业门户和移动应用程序的底层技术 , 但他们需要善于撰写编辑图像、横幅和其他内容等(这些工作用Instagram账号就能轻松做到) 。 Adobeaem是提供无代码/低代码内容创作的内容管理系统之一 。 新兴技术和云平台不断提出低代码和无代码的解决方案 , 而且这些解决方案也获得了需求市场广泛的接受 。 本文介绍了一种将业务操作外部化到低代码工具中实现的轻量级方法 , 使得具有各自领域专业知识的人员也可以实现业务规则方面帮上忙 。
虽然我们已经可以在市场上选用到很多规则引擎 , 比如Drools(它是一个功能丰富的业务规则管理系统)、EasyRules、RuleBook、OracleRulesSDK、Blaze(fico)、IBMDecisionManager等等 。 这些规则引擎通过各自的丰富特性(包括版本控制)以声明的方式启用规则管理 , 这对许多应用程序来说通常非常有用 。 然而 , 在某些不太复杂的解决方案中 , 它们往往是多余的 , 并没有得到充分利用 。 反而显得维护这个额外的组件更像是一种负债而不是一种资产 , 开销大于实际使用价值 。
在本文中 , 我们试图说明如何利用Java的固有特性 , 用尽可能简单的方式实现外部化规则 , 而不局限于附加框架的任何传递依赖 。 当技术规则(用Java编写的代码片段)需要外部化并且可能频繁更改时 , 这种方法非常有用 。 因此 , 这种方法在任何Java生态系统中都具有同等的价值 , 无论框架是什么 。 为从外部源(例如文件或URL)加载的规则提供一个简单的基于声明式模型的POJO , 这些规则是代表一个谓语或者一个等同于lambda表达式的Java代码片段 。 外部源的内容是Javalambda风格的表达式或Java代码片段 , 来源范围包括本地数据库及云资源 , 这样就可以实现在应用程序之外编写规则 , 甚至不需要应用程序停机 。 我们可以很容易地将其与Spring微服务和云配置进行集成 , 用不用云总线均可 。 这种方法提供静止加密以确保业务规则的安全性(机密性和完整性) 。 另外 , 除了支持Jasypt和SpringConfigCiphering之外 , 任何自定义安全性都可以插入其中 。
规则引擎:传统的方式
处理业务逻辑频繁变化的最传统和最理想的方法是规则引擎 。 规则通常是一组IF-THEN条件 。
规则≡前置条件+后续行动(RULE≡CONDITION+ACTION)
规则引擎是软件工具 , 简单来说 , 为我们提供了在源代码之外设置规则的能力 。 规则引擎使得半技术人员/非编程人员以不同的方式设置规则 。 利用领域特定知识 , 这些规则引擎可以提供GUI驱动的、直观的规则编写 。 Drools , DTRules , OraclePolicyAutomationsystem , Easy-Rules等就是常用的规则引擎 。
传统的规则引擎帮助领域专家能够脱离代码库编写规则集和行为 , 这对于复杂的大型业务环境非常有用 。 但对于较小的并不复杂的系统来说 , 考虑运行在本地或云基础设施上的经常性成本以及许可证成本等 , 结果证实 , 往往对于这类小系统、简单系统来说 , 规则引擎功能必要性大不 , 难以得到充分利用 。 对于小型团队来说 , 添加任何需要额外技能集的组件都是对带宽的浪费 。 一些商业规则引擎有陡峭的学习曲线 , 一直在追求更好的规则引擎性能 , 对用户使用的性价比考虑得比较少 。 在本文中 , 我们试图说明如何成功地在源代码之外维护规则 , 以执行在JavaTech-Stack(像SpringBoot)上运行的中型系统 , 使其他用户自定义定制这些规则更容易 。