在 DDD 中搜索聚合答案

【问题标题】：Searching across aggregates in DDD在 DDD 中搜索聚合
【发布时间】：2019-07-22 15:04:27
【问题描述】：

我在 DDD 中有以下场景。

public class Document
{
public int Id {get;set;}
public string DocumentCode {get;set;}
public int BuyerId {get;set;}
}

public class Buyer
{
public int Id {get;set;}
public string Name {get;set;}
}

现在我想搜索所有包含名称为“John”的买家的文档。

由于买方是不同的聚合体，我正在考虑这些场景

创建新聚合

public class DocumentSearch
{
public int Id {get;set;}
public string DocumentCode {get;set;}
public int BuyerId {get;set;}
public string Name {get;set;}
}

这里的“问题”是这个聚合需要监听任何买方更改并在本地应用更改。

保持原样。

在数据库级别创建一个视图，作为一个新的聚合。这里的问题是它违反了每个 DDD 原则，并且应用程序并不是真正无知的持久性

在应用级别进行搜索和加入

基本上在 Document 上进行搜索，在 Buyer 上进行搜索并在应用程序级别加入。我相信这需要更多的时间和精力，因为这两个集合最初都会更大，然后它们实际上应该在合并搜索中？

为了遵循 DDD 原则，有什么方法可以走？ CQRS 是终极解决方案，但我正在寻找 CQRS 途中的临时解决方案

【问题讨论】：

目前还没有 100% 适应 DDD，但您的班级 DocumentSearch 似乎实际上可能是搜索的（单个）结果之一。我想你可能想要一个搜索请求类，即class DocumentSearchRequest { public string NameToSearch { get; set; } }。在应用程序级别，使用请求类（小集）进行“应用程序级别的搜索和加入”并返回结果类的集合。原谅我可能有的任何 DDD 无礼（此时）:-)
根据 Greg Young 的说法，没有 CQRS 就无法完成 DDD。如果你不使用 CQRS，你应该预料到很多问题没有像这样的干净解决方案。

标签： architecture domain-driven-design code-first

【解决方案1】：

提出问题不应改变答案。

由于搜索不会改变答案，因此您通常不需要域模型或域实体来支持它。

通常的解决方案是 (a) 直接查询您的数据模型或 (b) 创建一个“读取模型”来支持查询。

(a) 正是它在锡上所说的。如果您将数据存储在 RDBMS 中，那么只需查询 -> dto? -> 响应。

读取模型通常用于查询支持不可行的情况。读取模型实际上是一个缓存的 DTO——随着事情的变化，您构建集合的表示。大多数情况下，您会看到这是异步完成的——针对“最新”表示运行查询，并运行后台工作流来传播对该表示的更改。

【讨论】：