问题In CQRS, should my read side return DTOs or ViewModels?的答案表明每个小部件应该有一个ReadModel（或者我认为这些是相同的）。
但是如果是这种情况，那么这不会将QueryHandlers移动到表示层中，因此每个小部件会有一个QueryHandler（在我的例子中是Angular中的组件）吗？
更具体地说：QueryHandler是否应该具有getReadModelForProjectPageSidebarById(< projectId >)之类的功能，或者它们应该具有getProjectById(< projectId >)之类的功能？如果后者是真的，那是不是意味着需要一个额外的层来将ReadModel映射到小部件/组件可以使用的ViewModel？
答案 0 :(得分：1)
确保这个想法很明确：每个“写模型”可以有多个“读取模型”。
从逻辑上讲，正在发生的事情并非与“非CQRS”情况完全不同;我们正在获取写模型记录的信息，将其转换为有趣的表示形式，并将其返回给客户端（在您的示例中，返回到小部件）。
但这并不一定要“活着”;我们可以通过返回表示的缓存副本来响应查询。
例如，如果您考虑网络上的资源 - HTTP已经深入了解了缓存。当从缓存中回答HTTP请求时，它基本上是对查询的纯粹表示处理，不是吗？
因此，如果您通过从缓存中返回表示来处理查询，那么处理程序将非常浅。
你仍然需要在某处使用 write 模型的“book of truth”表示并将其转换为适合缓存的表示。但是，该代码的执行不必与查询同步 - 您可以进行新鲜与延迟交易。
那么让我看看我是否理解正确，读取模型属于演示文稿，但查询处理程序属于应用程序层？你会说以下有意义吗？
那是......这一点都不错。
或者更重要的是，我的问题中的查询处理函数都不正确。正确的函数调用将是句柄行（＆lt; QueryForReadModelABC＆gt;类型的查询）。所以它实际上是对读取模型的请求，而不是对特定资源/实体（如项目或用户）的请求？
是。