业务规则引擎平台除了支持DMN决策模型以外应该有哪些功能？
DMN和决策模型的缺点对业务敏捷性、生产力和程序员工作量有很大影响。在这次讨论中，我确定了六个主要缺点：
缺点一、缺乏业务语义
如果你认为你可以在没有结构化的业务词汇和词汇表的情况下完成任何严肃的规则工作，你就是在自欺欺人。
业务规则的中心思想是使非程序员可以访问逻辑。如果不包含明确的业务语义，你怎么能做到这一点？！
缺点二、缺乏对行为规则的支持
规则引擎需要支持非常健康的行为规则。
行为规则是可以被违反或破坏的规则，它们管理持续活动的行为，因此对人员、组织和业务活动至关重要。
非常粗略地，您可以将行为规则视为业务约束。
它们还对数据质量产生巨大影响。
DMN决策模型不支持行为规则。
缺点3. 缺少对闪光点的支持
闪光点是指行为规则有可能被违反或需要被评估的事件。
一般来说，每个行为业务规则至少会产生两个闪光点（但通常不会超过4-5个）。
专门针对个别事件的行为业务规则确实存在，但它们只占少数。
考虑示例：
行为商业规则：使用积分预订的预订者必须是俱乐部会员。 |
对于这条规则，有四个闪点，如下所示：
- 创建预定积分。
- 持有积分预订的人被更改。
- 积分预订的预订者已经不再是俱乐部会员。
- 现有预订将转换为积分预订。
除非对上述四个所有闪光点规则进行评估，否则一些违规行为会被遗漏，这种遗漏对服务质量和数据质量有直接的影响。
事实上，这种遗漏是造成服务和数据这两个方面的质量缺陷的根本原因，在传统方案中往往是相当隐蔽的。
由于DMN和决策模型不承认或支持行为规则或闪光点，使用DMN和决策模型的应用系统必须自己评估行为规则和处理闪光点。这造成了巨大的程序员工作量。
将这项工作交付到规则平台上，将极大地提高生产力。
关于流程模型，DMN决策模型迫使建模者和软件开发者明确指出何时评估所有规则。
规则平台必须被告知何时评估规则。
对于许多决策问题，尽可能长时间地等待数据堆积往往才会产生最佳结果。
但是，你绝对不想等待很长时间以后才可以评估大多数行为规则，因为行为规则是一个实时的问题! 很明显，这个世界越来越实时了。
有没有想过为什么遗留系统经常产生如此不一致的结果？
一个很大的原因是程序员在编码和管理行为规则和闪光点。
对我来说，这不是一个建立商业系统的非常聪明的方法。它也不能很好地解决情感和人类的自由裁量权，这是另一个重要的实时问题。
缺点4. 缺少一个独立的观察者
那么，对行为规则和闪光点的实时支持的解决方案是什么？
关键是实时监控事件，独立于所有进程。
为此，你需要一个我称之为观察者的东西，就像足球比赛中的裁判，只不过是自动的。
这个观察者只对检测违反行为和执行闪光点的行为规则感兴趣。
观察者提供什么能力？
监控除流程之外的事件，以检测闪光点。
根据这些闪光点来评估行为业务规则。
为了实现这一目标，规则平台需要保持对状态的持续、不间断的认知--这是DMN和决策模型的另一个缺陷。
缺点5. 缺少对状态的认识
DMN决策模型对状态没有认识。从来没有一个观察者跟踪状态。
观察者必须全面了解正在发生的事情，因为有 100 个、1000 个或更多的事件几乎同时发生在几十个、100 个或更多的流程中，以及所有未建模的、临时性的交互。试图只用流程模型来同步事件是无望的--或者至少是无望的复杂。
状态的问题实际上把我们带到了上面讨论的第一个缺点。
处理业务状态的最好方法是支持业务语义（概念模型）。让我们在这里说得很清楚。我所说的 "状态 "是指业务状态--而不是软件状态。
DMN对流程模型的依赖巧妙地鼓励了对业务的程序性看法，在这种看法中，业务解决方案和系统模型很容易被混淆。
例如，我认为你不应该在分析和指定规则时看到关于同步流程的讨论，那是一个系统问题。但是你确实在 DMN 圈子里看到了这样的讨论（经常性的、长时间的） 。
缺点6. 缺少对自然语言的支持
DMN 和决策模型没有提供对规则的结构化自然语言表达的支持。它们就是不适合自然地纳入决策表。
政策手册、法律文件、科学和工程文件等通常不被表达为决策表。(有时，决策表可以以有用的方式进行改造，以达到实施的目的，但即使如此，也只是部分处理。那剩下的所有规则怎么办？程序员的工作量!
在这个你几乎可以用谷歌搜索任何东西的时代，缺乏自然语言支持[是根本不可能实现的。