制定决策时你一般从什么地方入手？你是否上传了一个预定义的对象模型？或者是用决策逻辑来开发它？

对象模型优先

根据我们的经验，在绝大多数的项目中，对象模型是已经存在，由IT部门定义并维护的。这非常合理，因为对象模型其实是决策服务在技术上和其他系统交互的一种约定。在执行决策服务应用前，我们需要知道它的全部功能。而调用系统也需要知道如何找到决策及其相关参数。

对象模型，或数据模型，亦或数据模式，实际上定义了与决策服务进行交互的数据结构。其中有一些区块（section）和字段（field）是输入数据，另有一些是输出数据。业务规则将直接确定或是通过计算得出这些数据。

在我们Sparkling Logic的体系里，我们将这些对象模型称为表单（form）。当你把某个申请视为数据时，表单就代表了该申请的数据结构，其中明确了每部分数据的含义。例如，“客户信息”是一个区块，包含了“姓名”、“出生日期”等字段。

尽管数据字段是业务规则的基础，但是字段的定义通常还是由调用系统来定义的。调用系统将产生交易消息（又称为交易数据），并在规则执行完成并做出最终决策后收回反馈消息。

总而言之，对象模型是由IT部门所有的，因为他们负责了实际的决策服务调用。

修改对象模型

那这是否意味着，业务部门无法修改对象模型？当然不是。通常我们希望通过计算和统计来丰富对象模型。“客户信息”可能会包含客户生日，但是业务规则可能是参考客户年龄制定的。那么通常的做法是增加一个“年龄”字段，用简单的公式就能计算出来。可以用类似的方式来添加更多的字段，以实现对更多数据的计算和统计，如共同借款人的总收入，或者计算债务收入比等。

在大部分系统中，这些计算字段对决策服务来说是不可见的，因此IT部门甚至都不知道这些字段的存在。

另一种非常类似的机制，就是向表单中添加业务术语（business term）。作为表单中业务概念的一种补充，业务术语构成了可以在项目之间共享的额外用语。例如，你可能想要一劳永逸地定义“老年人”这一概念的划分边界，而通过业务术语，甚至可以对每个州分别明确其边界值。业务规则无需重复定义这些条件就可以直接引用这些业务术语，比如：如果申请人是“老年人”并且他的家庭状况是“单身”，这里“老年人”和“单身”就是我们定义的两个业务术语。每一个引用了该表单的项目，都可以重用相同的术语，而不需要一遍又一遍地去定义它。

和计算字段类似，业务规则可以直接使用业务术语，而IT部门是不会看到这些术语的。

除了计算字段和业务术语，最终我们或许还会创建新的变量。没关系，引入中间变量以简化业务规则不会带来任何问题。尽管这些字段对于IT来讲是可见的，但是他们无需理会。作为中间变量，调用系统甚至可以不在数据库中保存这些值。

何时提供对象模型？

理想的做法是基于已经建立的对象模型来启动决策管理项目。上传数据建立数据结构，无疑是项目实施的第一步。不论你是否已经有实际的历史数据，还是为了规则的单元测试构建数据样本，这都是毋庸置疑的。

坦白讲，在具体编写规则之前建立好对象模型的原因是非常简单的。因为每次修改对象模型，那些依赖于对象模型（在我们的案例中是表单）中受影响部分的规则都需要重构。

当然，某些修改可能对规则没有影响。如果是这种情况，那自然可以简单愉快地拓展对象模型。

有些修改只是在表单内部移动区块和字段。只要受影响字段的类型保持不变，规则一般就无需重写。唯一的例外就是，规则在引用字段时不是使用了简写，而是使用了完整路径。例如，如果你的规则写的是“‘年龄’ < 21”，那么‘年龄’这个字段不论在哪里都是可以的；但如果规则写的是“‘客户’.‘年龄’ < 21”，那么当‘年龄’字段被移到了其他区块下时，就需要对其进行修改。

最后，有一些修改可能是影响相当大的。比如，在原先的保险政策中，一个保险申请只允许投保一个驾驶员，现在变成了一个保险申请允许投保多个驾驶员，保险申请与驾驶员数据从一对一变成了一对多。那么针对驾驶员的审核规则将必须考虑结构上的改变。你就必须要定义，年龄规则是适用于所有的驾驶员，还是任意一个驾驶员，亦或者是主要驾驶员。这就是规则重构可能带来的麻烦。

对象模型越稳定，就越适合编写规则。

这里我还想强调一件重要的事情，就是IT团队和业务分析团队需要充分沟通，并且在对象模型的字段使用上达成一致，要保证：

· 字段取值是明确地记录在文档中，并且都认可的：例如，使用缩写CA还是全称California

· 明确地知道具体哪些字段是输入字段：如果“州”这个字段出现在了多个地址中，知道哪个是优先级更高的

抱歉稍微有点离题，但这的确是我们看到的，“规则修复”工作中最占精力的地方

何时由规则决定对象模型？

这很少见但也确实会发生。我们大多是在一些新兴领域的项目中看到。这时候既没有业务记录数据库，也没有现成的基础结构，对这些新项目来讲预先定义好自己的对象模型是一种奢求。此时可行的选项也就只有：让数据建模人员来定义对象模型，或者随着业务规则的提炼来提取完善对象模型。

在这些案例中，我们往往会看到DMN（decision modeling and notation，决策建模与标记法）标准的权衡利用。当业务分析人员使用类似慧笔（https://www.sparklinglogic.com/pencil-decision-modeler/）这样的工具提炼源规则时，规则所用的词汇表也就得到了整合。

考虑到有不熟悉DMN的朋友，我这里概述一下这种方法。决策模型表示法可以通过分解决策逻辑，来指导业务分析人员。比如，你需要计算车险的保费，就需要确定基本费率和附加费率。要确定基本费率，你需要知道驾驶员的详细信息：年龄，风险等级和地址；你还需要知道车辆的详细信息：品牌，型号和年份。作为业务分析人员，需要深入到决策的各层次，直到完整获取了所有相关规则。

而词汇表就是你在此过程中遇到的所有属性的集合，如驾驶员的年龄、风险等级、地址、车辆的品牌、型号、年份，等等。这个过程中也会定义输入和输出属性。你也可以将这些属性组织到不同的类别中。当你完成了这些工作后，词汇表就可以被转化为一个表单，各个类别相当于表单的区块，各个属性相当于表单的字段。通过这种方法，你在完成决策逻辑制定的同时也获得了对象模型。

最后总结下

除了类似计算和中间变量的少量添加外，总体而言对象模型是从一开始就由IT部门所有并提供的。只有在新兴领域的项目中，才可能将规则和数据模型的获取相结合。