规则覆盖的妙用

接着我之前发布的内容（《同样的规则，对每人都是适用的吗？》【链接到第一篇】），我打算进一步聊聊一种技术，它通常被用来解决业务逻辑中的异常。你也可以查看我们主持的该主题研讨会的记录，发现更多的异常处理方式。

在我说明解决方案之前，我想先描述一下面临的挑战。假设你有一个想在各个单元（这些单元可以理解为地理位置、客户分群或客户端配置等等）持续推行的全局策略，比方说地理位置。众所周知，美国的各个州实行的法律条规是有很大区别的，这就要求我们在制定全局策略时，根据不同州的法律条规进行业务规则上的调整。

在某些情况下，我们只需要对业务规则稍作修改。但在其他一些情景中，现有的业务规则甚至可能违背了当地的法规，这时候我们就不得不排除这些业务规则了。当然还有一些情况，可能只需要添加一些业务规则。

不推荐的设计

直觉不一定总是正确的。

大多数情况下，我们看到的决策设计其实就是规则的复制与粘贴。这样做一开始会很简单，但当你的业务规则需要进行若干变动时，或者说当一个决策中规则集包含巨量的规则时，上述方案就不那么有效了。

进行其中的一个配置可能还是可行的，但后续的规则维护就如梦魇一般了。当你只需要更改其中一个规则时，通常的“查找-替代”功能可以节省时间。但这样做很容易出现人为的失误：你可能会漏掉某条规则的修改，也有可能因为规则些许的不同让其无法被“查找”到。同样，你需要思考并判断这些更改是否对每个配置项都适用。你是如何知道一个之前已经被覆盖的规则，是否应该受制于此次更改？

我们发现许多业务规则从业人员被上述问题所困扰，望着一堆散乱的、无法维护的规则而无所适从，徒留一堆无法实现的修改需求…

推荐的设计

一个清晰的设计需要遵循两个简单的原则：

ü  除非必须，否则不要将同一个规则反复复制

ü  记录好你的规则覆盖日志，无论是修改、添加或删除

谨记以上两点，我们就在业务规则和面向对象设计之间搭建了一个桥梁。对于商业分析人员来说，确实相对更容易理解业务规则，而不是引擎背后的工作原理。但不能否认的是，作为明策决策引擎的架构师或开发人员，我们在之前理解业务规则时候也同样遇到了很多问题。面向对象设计则使得在高层级定义属性和函数变得更简单，并允许任何继承的子类覆盖他们。但如果我们既能（向业务人员）隐藏这种实施的复杂性，也能为业务规则的维护提供一种强大的继承功能呢？

通过继承决策，你能在顶层定义你的规则，并自上而下指定层级结构。这种结构的魅力之处在于当业务分析师在最高政策层做出修改时，继承链下的各个继承决策也能随之得到修改，而不需要重复操作。这样做不仅让规则调整变得容易，相关测试也变得一目了然。你可以快速运行一个模拟并评估这些更改带来的业务影响，而无需花费数天等待分析师团队进行项目调试后再进行效果评估。

让我们用一个具体案例进行说明。比如当需要更改加利福尼亚州的业务规则时，我们首先需要查看其母规则。我们认为将这些规则设置成只读是必要的，以避免全局规则受到影响。如果一位负责加州业务的分析师在维护加州业务规则时，却不小心影响到了全局规则，那就真是一场灾难了。但当他必须做出上述更改时，将规则进行覆盖就很有必要了。如此一来，这个规则就可以被修改，并且新规则仅对加州和所有从这继承的子决策（如旧金山、圣迭戈、洛杉矶等等）有效。更改方式可以是对相关规则进行修改、添加或删除。

这个方法的优势在于你不需要知道加州地区具体有哪些业务规则。管理链很清晰，你能在任何时候对覆盖的规则与主规则进行比较，并且层级的数量是不会影响结果的。一个有趣的想法是你能为各个层级或分支分配权限。而然我们经常发现由于缺乏真正的协同工作工具，业务分析师们在管理业务规则时无法进行实时合作。这个（协同工作）架构能让各层级的规则业务人员进行有效沟通，共享业务经验和专业知识。

使用以上方式后，（业务规则）并不会成几何级增长，让项目在结构精简化的同时仍能拥有快速的运行速度。

原文作者：Carole-Ann Berlioz

原文地址：https://www.sparklinglogic.com/override-rule/