domain-driven-design - 域驱动设计中的搜索查询和搜索结果

Question

我有一个包含新闻帖子的网络应用程序。这些新闻帖子应该是可搜索的。 在 DDD 的上下文中，搜索查询和搜索结果是什么样的构建 block ？

这是我的想法

他们都没有身份，因此他们不是实体。但是没有标识并不意味着它们是值对象。正如 Eric Evans 所说:

However, if we think of this category of object as just the absence of identity, we haven't added much to our toolbox or vocabulary. In fact, these objects have characteristics of their own and their own significance to the model. These are the objects that describe things.

我想说两者都是值对象，但我不确定。让我感到困惑的是我在 Internet 上找到的示例。通常值对象是其他实体的一部分，它们不是“独立的”。 Martin Fowler给出例如货币或日期范围对象。 Adam Bien事件将它们与枚举进行比较。

如果将搜索结果视为值对象，那将是由实体组成的值对象。我不确定这完全没问题。

我不认为它们是 DataTransferObject。因为我们目前不关心层之间的数据传输，但我们关心的是它们在没有层的情况下对模型的意义。

我不认为搜索查询是命令。因为这不是变更请求。如 CQRS 所述

People request changes to the domain by sending commands.

我正在尝试使用和学习 DDD，有人可以向我澄清这个问题吗？我的推理哪里出了问题？

Answer 1

简单的答案是查询可能不属于您的领域。域模型不是用来服务查询的，它是用来在你的域中强制执行不变量的。由于本质上查询是只读的，因此没有要强制执行的不变量，那么为什么要使事情复杂化呢？我认为人们在使用 DDD 时通常会出错的地方是他们假设因为他们在“做 DDD”，所以系统的每个方面都必须由域模型处理。 DDD 可以帮助处理复杂的业务规则，并且只应在您实际拥有它们的时间/地点应用。此外，您可以而且可能应该有许多模型来支持每个限界上下文。但那是另一个讨论。

您提到 CQRS 很有趣，因为它代表什么？命令查询职责分离。因此，如果命令使用域模型，并且查询责任与其分离，那么它告诉您做什么？答案是，做任何最容易查询和显示该数据的事情。如果 select * from news table filled to dataset 有效，那就去吧。如果您更喜欢 Entity Framework ，那就去吧。无需获取查询涉及的领域模型。

我想说的最后一点是，我认为很多人都在将 DDD 应用到没有太多业务不变量可执行且领域模型最终看起来很像数据库的情况下。确保您使用正确的工具来完成工作，而不是使事情过于复杂。此外，您应该只在系统中存在这些不变量的区域应用 DDD。这不是全有或全无的情况。