图1：嵌入式业务规则的进程
图1中的过程中的2个网关和3个活动可以表示为DMN中的单个决策图：
图2：DMN的折扣决定（1）
图1的业务流程是从真正的业务实践的角度理想化的。实际上，折扣和忠诚度计划要复杂得多。它们涉及许多规则，而且在参与“忠诚”计划之前，往往受到法律协议的约束。这通常会压倒简单的决策表，解决方案是由程序员开发的。管理这种复杂性正是DMN许多功能背后的基本原理。复杂性通常涉及到数据列表:订单有细节，交互有历史事件流。随着多实例决策(MID)的引入，还出现了另一种简化流程的方式:在一个或多个活动中例行编写脚本的服务可以在DMN中建模。
图3：DMN的折扣决定（2）
在此场景中，从客户处接收订单。该订单有多个项目，每个项目都有一个请求的数量和报价。订单流程检查是否存在与市场营销和广告相匹配的促销折扣。在Compute Prices脚本活动中，计算机代码为每个订单行和总数定价。如果已经分配了产品折扣，那么它将与订单行匹配，并应用折扣。随着多实例决策的引入，可以用DMN中的决策模型替代图3中的脚本活动Compute Prices。执行此操作的DRD如下所示:
图4:DMN中的折扣决策(3)
在客户订单输入数据中，如图4所示，是一个复杂类型，它包含一个order Items列表。订单项目包括项目编号(SCU)和请求的数量。MID提取订单行中的每条记录，并公开数量以进行定价。多实例决策用封闭形状定义:
MID迭代所选列表的决策和表达式。列表包含在输入数据中——其中输入数据是列表或复杂类型。图4中的客户订单是一个复杂类型，它包含一个订单行列表。当你配置MID时，输入数据元素，Order行，会自动放置在方框中。如果一个问题有多个维度，MID可以在一个MID中。你经常需要静态数据，这些数据不会随着记录的迭代而改变。例如，您可能将一个数字与所有记录进行比较。为此，输入数据应该在MID框之外。例如，图4中的Special Discount输入项保持不变。
简化的过程如下:
图5:简化过程，显示与规则形状“计算价格”相关的决策。
中期的好处
没有中期，客户订单的价格可能会在“Java脚本”中计算，解决方案看起来像：
函数compute_prices（）{var len = server_items.length var total_price ...对于{1 = 0;我 业务分析师不容易理解此代码片段，更不用说创建和维护。中期与简单的决策表相反，中间有一点复杂性;但是，对于商业分析师和其他利益相关者可以有这些福利： MID通常可以替换多个活动和网关，并且可以创建更强大的解决方案。 DMN模型比代码更好，因为它在决策表和表达式中使用了可理解的图形符号和逻辑。Signavio Decision建模器中的决策表采用了许多熟悉的Excel控件和概念。用MID包围单个项目的基本逻辑，简化了代码中循环的概念。MID的概念很容易理解和应用。此外，模拟和测试允许设计者精确地创建所需的逻辑。有许多决策用例可以利用MID: 在过去的逻辑中，所需列表被降级到计算机编码或脚本的进程活动。这样做的一个原因是，决策表或生产规则尚未容易地解决这些类型的数据集。MID克服了这一点，大大扩大了DMN可以解决的问题。
讨论
