关于ReadModels和Domain的DDD / CQRS混淆 [英] DDD/CQRS confusion regarding ReadModels and the Domain

问题描述

因此，经过大量阅读之后，我现在意识到，复杂的报告功能不属于您的典型存储库，并且需要某种专用的 Finder来返回仅用于报告的只读对象。

So after much reading I've now come to the realization that complex reporting functions do not belong in your typical Repository and that there needs to be some kind of dedicated "Finder" which returns read only objects to be used in reporting.

我不清楚什么是 Finder类及其关联的ReadModel类应该放在我的项目中？查找器是否像存储库一样，您在基础结构程序集内部拥有查找器的接口以及具体的Readmodels？

What I'm unclear on is where the "Finder" classes, as well as their associated ReadModel classes are supposed to go inside my project? Are the finders like repositories in that you have an interface for the finder inside the infrastructure assembly along with concrete Readmodels?

这些类在哪里？

推荐答案

我通常有一个逻辑查询图层。这是合乎逻辑的，因为我并不总是需要将其分成自己的程序集（从.Net / C＃角度来看）。它不应在您的域中，因为该域不应查询IMHO。领域涉及集合，实体，值对象等。它需要的其他任何内容都需要馈送到域对象中。

I usually have a logical query 'layer'. Logical since I do not always need to have it separated into its own assembly (from a .Net/C# perspective). It should not be in your domain since the domain should not be querying IMHO. The domain is concerned with aggregates, entities, value objects and the like. Anything else it needs would need to be fed into the domain objects. The querying bit probably comes into play more on the application service edge.

然后我最终得到的是我的存储库仅返回所需的完整聚合/实体和单独的 IQuery 接口已在读取端实现。通常，我将它放在 DataAccess 程序集中。例如：

What I then end up with is my repositories returning only the required full aggregates / entities and a separate IQuery interface implemented on the read side. Typically I have it in a DataAccess assembly. For instance:

public interface IUserQuery
{
    bool ContainsEMail(string emailAddress);
    int NumberOfAdminisitrators();
    DataRow Profile(Guid id);
    DataTable FriendRequests(Guid id);
    SomeReadModel ForSomethingThatContainsSayAList(DateTime date);
}

您会注意到，我会使用简单的类型（如果可以）和技术特定的数据访问权限 DataRow ， DataTable ，从不 DataSet ：） ---尽管 DataSet 可以用于复合数据，但是有点麻烦。

You will notice that I use simple types if I can and technology specific data access objects like DataRow, DataTable, never DataSet :) --- although DataSet may be used for composite data but it is somewhat cumbersome.

我尝试将特定的读取模型（DTO）保持在最低水平，但在处理复合数据时可能偶尔需要使用它们。

I try to keep specific read models (DTOs) to a minimum but every once in a while they may be required when dealing with composite data.

这篇关于关于ReadModels和Domain的DDD / CQRS混淆的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！