时间戳

首页 > 解决方案 > 在 DDD 中搜索聚合

architecture - 在 DDD 中搜索聚合

问题描述

我在 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;}
}

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

保持一切原样。

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

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

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

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

标签： architecturedomain-driven-designcode-first

解决方案

问一个问题不应该改变答案。

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

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

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

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

推荐阅读