创建单个标签映射到多个值的域答案

【问题标题】：Creating a domain where a single label maps to multiple values创建单个标签映射到多个值的域
【发布时间】：2017-07-11 20:08:57
【问题描述】：

我的输入数据具有多个值可以引用单个业务友好语言（域标签）的属性。我试图弄清楚如何在规则设计器中表示这一点。我是 ODM 新手，仍在学习中 - 目前使用的是 ODM 8.8.1（分布式/Java）。

想象一下将邮政编码前缀映射到它们的状态。例如，以 967 和 968 开头的邮政编码是夏威夷。简而言之，我想将规则表达为“如果邮政编码前缀是夏威夷......”而不是与 967 和 968 进行比较。在领域术语中，967 和 968 是真正的底层属性值，夏威夷是语言化标签。但显然 BOM-to-XOM 期望单次返回，随意选择 967 或 968 是不对的。

我的实际场景要复杂得多，涉及用户永远不会知道或识别的长串神秘代码值，但概念是相同的。在某些情况下，一个标签可以映射到 15 或 20 个基础值。

ODM 域可以做到这一点吗？（我很确定它可以用决策表在另一边完成，但我现在真的想把它作为一个域问题来解决。）

【问题讨论】：

标签： ibm-odm

【解决方案1】：

这里最好的方法是创建一个 XOM 或 BOM 类来将状态映射到前缀，然后用你想要的语言来包装它。我将用一个将邮政编码映射到州的示例进行说明。

例子：

使用您的状态设置枚举或域：

public enum States
{
	AL,
	AK,
	AZ
  // etc
 }

为您的邮政编码创建一个类：

public class Zipcode
{
	private String zipcode;

	public String getZipcode()
	{
		return zipcode;
	}

	public void setZipcode(String zipcode)
	{
		this.zipcode = zipcode;
	}
	
}

创建一个扩展类来执行邮政编码到州的映射：

public class ZipToStateMap
{
	private Map<String, States> zipToStateMap = new HashMap<String, States>();
	
	public ZipToStateMap()
	{
		zipToStateMap.put("99553", States.AK);
		zipToStateMap.put("99571", States.AK);
		// etc
	}
	
	public States getStateFromZip(String zip)
	{
		return zipToStateMap.get(zip);
	}
	
	public boolean zipIsInState(String zip, States state)
	{
		return this.getStateFromZip(zip) == state;
	}
	
}

创建一个使用 ZipToState:zipIsInState() 扩展器的虚拟 bom 方法：

使用您的新映射编写规则：

【讨论】：

您介意包含一些代码 sn-p 或更多指导吗？从技术上讲，这是一个单行答案。
我不需要一个类，但我在 BOM-to-XOM 中添加了一些 if-string-contains 测试来转换多个真实世界的 XOM 值，返回单个 BOM-only 代码.真正的 XOM 字段没有用语言描述。在我的示例上下文中，如果真正的 XOM 数据是 967 或 968，则 BOM 将返回一个代码“50”，为我们提供一个单一的值来表达为“夏威夷”。

【解决方案2】：

也许可以使用 ODM 域来解决这个问题，但我怀疑这将是最好的解决方案，因为这不是域的预期用途。如果您想要一个可以在规则中引用的州列表或邮政编码前缀列表，那么 ODM 域是一个很好的解决方案。但是要维护一个州与其邮政编码前缀之间的映射，我不太确定。 ODM 域不提供获取域的可能值的方法，这与提供 .values() 方法的 Java 枚举不同。

您是否担心维护邮政编码前缀和州之间的映射？您是否希望业务用户维护映射？

不使用 Java 的一个选项是定义一个规则集变量来保存夏威夷的邮政编码前缀列表。如果我们假设变量被表述为“夏威夷邮政编码前缀”，那么规则可以表示为“如果邮政编码前缀是“夏威夷邮政编码前缀”之一，那么......”。

规则覆盖和分层属性也有可能适合您的情况。但这是一个复杂且很少使用的功能。

【讨论】：

真实场景是我们从一个古老的大型机数据库中获取的大量复杂的、对人类不友好的代码列表，这些代码映射到金融资产类型。它们很少改变（我可以想到在近 20 年内可能会增加两到三个）。我对已接受答案的回复说明了我是如何解决的。
我也有类似的情况。 ODM 域是一个更好的解决方案，因为我可以将域存储在 EXCEL 文件中，这意味着业务人员可以在没有 IT 部门帮助的情况下进行更改和部署 :) 这是 ODM 对企业的主要好处....尽可能不编写任何 Java 代码。