CQRS - QueryHandlers 属于哪一层?

CQRS - What layer do QueryHandlers belong to?

问题 In CQRS, should my read side return DTOs or ViewModels? 的答案表明每个小部件应该有一个 ReadModel(或投影,我假设它们是相同的)。

但如果是这种情况,那么这不会将 QueryHandler 移到表示层,这样每个小部件就会有一个 QueryHandler(在我的例子中 Angular 中的组件)?

更具体地说:QueryHandler 应该具有 getReadModelForProjectPageSidebarById(< projectId >) 之类的功能还是应该具有 getProjectById(< projectId >) 之类的功能?如果后者是真的,那是否意味着需要一个额外的层来将 ReadModel 映射到 widget/component 可以使用的 ViewModel?

确保这个想法是明确的:每个“写模型”可以有多个“读模型”。

从逻辑上讲,正在发生的事情与“非 CQRS”情况并没有什么不同;我们正在获取写入模型记录的信息,将其转换为有趣的表示,并将其返回给客户端(在您的示例中,返回给小部件)。

但这并不一定要“现场”完成;我们可以通过返回表示的缓存副本来响应查询。

例如,如果您考虑 Web 上的资源——HTTP 已将对缓存的深刻理解融入其中。当从缓存中响应 HTTP 请求时,它基本上是对查询的纯粹表示处理,不是吗?

因此,如果您通过从缓存返回表示来处理查询,那么处理程序将非常浅。

您仍然需要在某处使用 write 模型的“真理之书”表示并将其转换为适合缓存的表示的代码。但是该代码的执行不必与 查询 同步——您可以在新鲜度与延迟之间进行交易。

So let me see if I understand this correctly, the read model belongs to the presentation, but the query handler belongs to the application layer? Would you say that the following makes sense?

https://imgur.com/9ndFL3h

那是……一点也不差。

Or more importantly, neither of the query handler functions in my question are correct. The correct function call would we something along the lines of handle(< query of type QueryForReadModelABC >). So it's actually a request for a read model, and not a request for a specific resource/entity such as Project or User?

是的。