domain-driven-design - 流口水与 DDD : Does Drools require Flat Object Models?

Question

在我们的电子商务领域，我们有一个使用嵌套数组建模的实体层次结构。我们使用领域驱动设计的原则(如 Eric Evans 所解释的)来做到这一点。我们电子商务领域的核心概念是:

合约，有交易所，每一个都有服务和付款。反过来，服务具有描述每个服务的特征。

这种分层模型使我们能够表达任何契约(Contract)，无论多么复杂，包括具有多个协议(protocol)(即交易所)作为整体协议(protocol)(或契约(Contract))的一部分的那些。

Drools 不支持这种分层对象模型吗？我应该将我的对象模型反转为没有数组的平面对象模型(如“Fires HAVE Rooms”和“Sprinklers HAVE Rooms” example in the Drools Expert documentation)，如下所示？

契约(Contract)。

交易所，每个交易所都有一个合约。

服务和支付，每个都有一个交易所。

功能，每个功能都有一个服务。

以这种方式将分层对象模型反转为具有原子断言的平面对象模型，这在 Drools 中受支持并且效果最好，我对吗？ Drools 似乎不支持对事实和子集合中的事实具有 LHS 条件的规则。

如果是这样，为什么 Drools 不支持更多层次的对象模型？是不是因为 Drools 来自 AI 世界(不是面向对象的世界)，在这个世界中，一阶逻辑将所有事实表达为原子的主-谓-值语句，而不是实体对象具有身份、值(value)的面向对象世界对象没有身份，实体对象由其他实体和值对象组成？

Answer 1

您可以针对任何 Java 对象模型定义规则。

该文档提供了基于玩具问题的示例，以避免分散注意力。不是因为 Drools 无法处理更复杂的模型。如果您进一步阅读手册，您将看到使用诸如“包含”或累加器之类的语法处理列表的示例。

这取决于你如何建模。您可以将契约(Contract)、交易所、服务、付款和功能作为单独的事实插入，它们相互引用。或者，您可以只插入一个复杂的契约(Contract)事实，其中包含交易所列表，其中包含服务列表等。

哪个对您更有效取决于您的规则是否与具有很少链接的契约(Contract)相匹配，或者您是否希望规则对功能的更改或付款事实的插入等使用react。