DMN比Microsoft的Power FX等更知名的低代码语言更有利于商业，也更强大。
其中一个原因是DMN的上下文盒装表达式，它将复杂的业务逻辑或决策逻辑分解成多个简单的部分，而不会用几十个小决策使DRD混乱。上下文是一个两列表，第一列命名上下文的本地新变量，第二列命名其值的 FEEL 表达式。此表达式既可以引用整个上下文的输入，也可以引用先前的上下文条目。任何对FEEL有基本了解的人都可以理解这些表达式中的每一个的逻辑。因此，除了简化DRD并使其更易于管理之外，上下文还提高了逻辑透明度。即使你自己无法弄清楚如何实现一些复杂的逻辑，如果你知道FEEL，你就可以把它理解为在上下文中分解。
示例：有多少假期？
输入休假请求包括休假开始和休假返回日期，均为 FEEL 类型日期。决策“申请天数”返回员工请求的休假天数。听起来很简单，对吧？从返回日期中减去开始日期得到一个持续时间，将其除以一天的持续时间得到天数。是的，但这只是一个原始计数。原始天数还包括周末和可能的节假日，这些不应包含在请求天数的计数中。嗯，这有点复杂。让我们看一下日历，看看你是否能弄清楚如何做到这一点。
假设假期开始时间是 10 月 5 日，请注意 10 月 10 日是假期。 验证规则确保假期开始和假期返回都不会是周末或节假日。为了找出其中的逻辑，让我们看看假期返程（第一天上班）的 4 种可能性：
l 如果休假返回日期为 10 月 11 日，则请求的天数为 3。
l 如果休假返回日期为 10 月 13 日，则请求的天数为 5。
l 如果休假返回日期为 10 月 17 日，则请求的天数为 7。
l 如果休假返回日期为 10 月 19 日，则请求的天数为 9。
那么问题是，给定任何假期开始和假期结束的通用逻辑是什么？ 尝试自己推导它，然后继续阅读。
逻辑梳理
DMN 的新手通常会发现对逻辑的每一位使用单独的决策更容易，而不必担心弄乱DRD。所以让我们这样做。
我们从原始天数开始，如前所述，该数字是通过从假期回报中减去假期开始并除以一天的持续时间来计算的。
原始天数 =（休假请求.休假返回 – 休假请求.休假开始）/持续时间（“P1D”）
为了调整原始天数要考虑周末，我们需要考虑间隔中包含的周末数。每个从请求天数中减去2天。为了获得包含的周末数，我们需要整周数，我们将通过将原始天数除以7并使用 FEEL floor（）函数丢弃任何分数值来获得。
整周 = floor（原始天数/7）
要发现一般公式，让我们寻找模式：
假期回报为 10 月 11 日，整周 = 0，请求天数 = 3 = 6 个原始天数 – 2 个周末 – 1 个假期
假期回报为 10 月 13 日，整周 = 1，请求天数 = 5 = 8 个原始天数 – 2 个周末 – 1 个假期
假期回报为 10 月 17 日，整周 = 1，请求天数 = 7 = 12 个原始天数 – 4 个周末 – 1 个假期
假期返回日期为 10 月 19 日，整周 = 2，请求天数为 9 = 14 个原始天数 – 4 个周末 – 1 个假期
请注意，包含的周末数量不仅仅取决于整周。 还需要什么？这与假期返回的星期几有关。如果一周的休假返回日早于一周的休假开始日，则整周将周末少算 1。在这种情况下，从原始天数中减去周末天数应为 2*(整周 + 1)， 否则为 2*整周。 幸运的是，FEEL 中的日期具有工作日属性，从 1 到 7 的数字表示星期几，即周一到周日。 因此我们可以将决策周末调整天数定义为：
我们还需要一个要排除的假期表，例如这样的：
我们对法定假日应用过滤器，以列出间隔内的任何包含的假日：
这表示从“法定假日”表中选择日期组件值在请求的休假间隔中的所有行。然后我们只需计算它们：
最后，我们从原始天数中减去周末调整天数和假日计数：
我们可以在 DMN 中使用下面的 DRD 对所有这些进行建模：
此模型中每个决策的表达式都很简单。任何有一点 FEEL 知识的人都会理解它们。但这从来都不是最难的部分。困难的部分是梳理逻辑。当人们说FEEL对商业用户来说很难时，他们的意思是梳理逻辑可能很难。
使用上下文进行简化
这里我们只是试图从休假请求中获取申请天数，这需要一个具有7个决策的DRD。在实践中，获取此计数只是我们尝试使用休假申请执行的众多事情之一，如果我们需要为每个决策做出7个决策，我们将拥有一个包含数十个节点的 DRD，这使得它难以维护。这就是上下文的用武之地。上下文允许我们将逻辑分解为小步骤，而不会使 DRD 混乱。有了上下文，我们的 DRD 看起来像这样一个单一的决定。
上下文如下所示：
现在我们用4个上下文条目，每个条目定义一个决策局部变量。每个逻辑都与我们之前得出的结果一样。当你没有梳理出逻辑时，它看起来很复杂。但是现在你已经梳理清楚逻辑的时候。我们所做的只是将具有7 个决策的 DRD 简化为等效但更简单的东西。请注意，在上下文中，每个值表达式都可以引用决策输入休假请求和任何前面的上下文条目。因此，例如，“整周”引用先前条目“原始天数”。此处底部的最终结果框仅引用上下文条目，从而简化了表达式。
因此，DMN实际上提供了两个级别的逻辑分解：DRD和每个决策中的逻辑分解，也可能是一个上下文。建模者有机会平衡每个部分的分解量。如果你认真地进入DMN，你会一直使用它。
上下文的价值
虽然许多所谓的DMN工具仍然不支持上下文，但它们显然为建模者提供了两个重要的好处：
1.它们允许分解复杂的值表达式，而不会给 DRD 增加混乱。在现实世界的决策模型中，这是一个重要的考虑因素。
2.它们提供逻辑透明度，特别是与表示为单个文字表达式的等效逻辑相比。即使您自己无法弄清楚逻辑，FEEL 的基本知识也可以在建模为上下文时使逻辑变得透明。
