时间戳

首页 > 解决方案 > 什么层应该包含 DDD 中的查询

repository - 什么层应该包含 DDD 中的查询

问题描述

我有一个简单的 DDD 服务，带有文章聚合根。我使用 MediatR 和 CQRS 来分离命令和查询。在 DDD 域中不应依赖于应用程序和基础设施层。我有一个存储库 IArticleRepository 用于组合文章数据库中的一些数据。我有一个休息端点，用于通过某种过滤器获取文章，以便我创建

ArticleQuery : IRequest<ArticleDto(or Article)>

这个查询对象应该是什么时候？我每个聚合都有一个存储库，所以在域层我有 IArticleRepository。我需要指定输入参数类型。如果我将查询放在基础设施或应用程序层，我会从指向基础设施或应用程序的域中获得依赖关系。如果我将查询放在域中，则违反 DDD，因为查询与业务无关。如果我不放一个对象，而只是将字段作为参数放入存储库，那么将有大约 10-15 个参数 - 这是一种代码味道。

之所以需要它，是因为在查询处理程序中也出现了 SearchEngine 逻辑，所以我决定通过存储库或类似的东西将来自搜索引擎逻辑的 SQL 逻辑封装在基础设施中。

标签： repositorydomain-driven-designcqrs

解决方案

我通常会选择各种查询层。就像我有一个ICustomerRepository可以处理我的聚合一样，我也会有一个ICustomerQuery直接与我的数据存储交互的。

存储库实际上应该仅用于聚合，因此仅用于数据修改。唯一的检索应该是检索整个聚合，以便对该聚合产生某种形式的更改。

查询层（实际上比layer更受关注）是基础设施。我通常还在命名空间中命名任何读取模型，Query以便区分我的 domainCustomer和 my Query.Customer.

推荐阅读