在我的职业生涯中，我见过许多不同行业的项目。它们适用于完全不同类型的决策。我时不时听到一些人想要简化决策结果的想法。‘某些情况下’仅仅做出一个决策是不够的。不要假定没有决策就等同于与其相反的决策。这种过于简化的做法不是一个好的设计。决策服务需要做出多个决策。

业务规则通常会标记出负面的结果，例如一个拒绝的决策、疑似欺诈等。一个诱人的想法是决策服务只在反面的行为发生时才做出响应。如果申请人没有被拒绝或转介，那么他或她的申请就被批准了。既然这是显而易见的事实，为什么还要明确地表述呢？

在这样的设计中，决策服务将在申请人被拒绝时返回"已拒绝"，而当申请人没有被拒绝时，则不会返回任何信息。

把糟糕的情况标注出来并不是什么坏事。同时我个人坚信正面的决策结果也需要肯定地表述出来。决策服务所给出的最终结果都是“申请被拒绝”，这是不够的。如果符合申请规则，它应该能反馈结果“申请已批准”。只关注否定的结果似乎会很直观，但没有返回任何结果未必就是正面的，也可能是由于缺乏信息而无法对申请人进行审查。

不要让决策服务做出的决策有任何的不确定性。

你当然可以认为‘没有错误的决定’等同于‘正确的决定’。不过我觉得这逻辑有点站不住脚。当出现例外状况时，在这种逻辑下会得出一个肯定的结果（“申请被批准”），这会使你的业务遭受损失。如果你的决策逻辑在中间步骤失败了，不要忽视了这一信息。

不要因此臆断我不信任业务规则。显然，业务规则会忠实地重现您所创建的决策逻辑。我担心的是数据会随着时间的推移而改变，既定的决策逻辑也会同样改变，而且很频繁。

不要想当然地认为所有可能的路径都被覆盖了。当前你的规则可能会检查是否所有必需的信息都已经提供了。假设第二天你的决策服务需要一个新数据，而负责该数据相关规则的业务分析师忘记提前检查，缺少此数据时，将无法做出决策。最终你会得到许多一开始就无效却被批准了的申请。

简而言之，我强烈建议为例外事件做好准备，不要让它在不经意间发生。一定要清楚地表述你的决策。如果申请没有被“拒绝”或“转介”，则添加一条规则将状态设置为“已批准”。如果遇到这些无法做出决策的情况，只需要相应地更新你的决策逻辑。另外，这会大大增加在质量检查时发现这些问题的机会。你也不希望在决策逻辑部署到生产环境后还出现混乱。这就是关于做决策的101规则。