规则覆盖的妙用
接着我之前发布的内容(《同样的规则,对每人都是适用的吗?》 ),我打算进一步聊聊一种技术,它通常被用来解决业务逻辑中的异常。你也可以查看我们主持的该主题研讨会的记录,发现更多的异常处理方式。
在我说明解决方案之前,我想先描述一下面临的挑战。假设你有一个想在各个单元(这些单元可以理解为地理位置、客户分群或客户端配置等等)持续推行的全局策略,比方说地理位置。众所周知,美国的各个州实行的法律条规是有很大区别的,这就要求我们在制定全局策略时,根据不同州的法律条规进行业务规则上的调整。
在某些情况下,我们只需要对业务规则稍作修改。但在其他一些情景中,现有的业务规则甚至可能违背了当地的法规,这时候我们就不得不排除这些业务规则了。当然还有一些情况,可能只需要添加一些业务规则。
直觉不一定总是正确的。
大多数情况下,我们看到的决策设计其实就是规则的复制与粘贴。这样做一开始会很简单,但当你的业务规则需要进行若干变动时,或者说当一个决策中规则集包含巨量的规则时,上述方案就不那么有效了。
进行其中的一个配置可能还是可行的,但后续的规则维护就如梦魇一般了。当你只需要更改其中一个规则时,通常的“查找-替代”功能可以节省时间。但这样做很容易出现人为的失误:你可能会漏掉某条规则的修改,也有可能因为规则些许的不同让其无法被“查找”到。同样,你需要思考并判断这些更改是否对每个配置项都适用。你是如何知道一个之前已经被覆盖的规则,是否应该受制于此次更改?
我们发现许多业务规则从业人员被上述问题所困扰,望着一堆散乱的、无法维护的规则而无所适从,徒留一堆无法实现的修改需求…
推荐的设计
一个清晰的设计需要遵循两个简单的原则:
- 除非必须,否则不要将同一个规则反复复制
- 记录好你的规则覆盖日志,无论是修改、添加或删除
谨记以上两点,我们就在业务规则和面向对象设计之间搭建了一个桥梁。对于商业分析人员来说,确实相对更容易理解业务规则,而不是引擎背后的工作原理。但不能否认的是,作为明策决策引擎的架构师或开发人员,我们在之前理解业务规则时候也同样遇到了很多问题。面向对象设计则使得在高层级定义属性和函数变得更简单,并允许任何继承的子类覆盖他们。但如果我们既能(向业务人员)隐藏这种实施的复杂性,也能为业务规则的维护提供一种强大的继承功能呢?
通过继承决策,你能在顶层定义你的规则,并自上而下指定层级结构。这种结构的魅力之处在于当业务分析师在最高政策层做出修改时,继承链下的各个继承决策也能随之得到修改,而不需要重复操作。这样做不仅让规则调整变得容易,相关测试也变得一目了然。你可以快速运行一个模拟并评估这些更改带来的业务影响,而无需花费数天等待分析师团队进行项目调试后再进行效果评估。
让我们用一个具体案例进行说明。比如当需要更改加利福尼亚州的业务规则时,我们首先需要查看其母规则。我们认为将这些规则设置成只读是必要的,以避免全局规则受到影响。如果一位负责加州业务的分析师在维护加州业务规则时,却不小心影响到了全局规则,那就真是一场灾难了。但当他必须做出上述更改时,将规则进行覆盖就很有必要了。如此一来,这个规则就可以被修改,并且新规则仅对加州和所有从这继承的子决策(如旧金山、圣迭戈、洛杉矶等等)有效。更改方式可以是对相关规则进行修改、添加或删除。
这个方法的优势在于你不需要知道加州地区具体有哪些业务规则。管理链很清晰,你能在任何时候对覆盖的规则与主规则进行比较,并且层级的数量是不会影响结果的。一个有趣的想法是你能为各个层级或分支分配权限。而然我们经常发现由于缺乏真正的协同工作工具,业务分析师们在管理业务规则时无法进行实时合作。这个(协同工作)架构能让各层级的规则业务人员进行有效沟通,共享业务经验和专业知识。
使用以上方式后,业务规则并不会成几何级增长,让项目在结构精简化的同时仍能拥有快速的运行速度。
原文作者:Carole-Ann Berlioz
原文地址:http://www.xinshu.ai/blog.html/30