DDD 中哪一层应该包含查询

And*_*riy 3 domain-driven-design repository cqrs

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

ArticleQuery : IRequest<ArticleDto(or Article)>
Run Code Online (Sandbox Code Playgroud)

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

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

Ebe*_*oux 12

我通常会选择某种查询层。正如我会有一个ICustomerRepository处理我的聚合的容器一样,我也会有一个ICustomerQuery直接与我的数据存储交互的容器。

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

查询层(实际上比层更受关注)是基础设施。我通常还会在命名空间中命名任何读取模型Query,以便区分我的域Customer(例如)和我的Query.Customer.