我们正在通过CQRS服务实现REST API。我们当然不希望向REST API的用户公开我们的任何域。
但是，CQRS的主要租户是所读取的模型通常对应于特定的视图或屏幕。
在这种情况下，逻辑上合理的是，我们的REST API中的资源将与查询中的读取/视图模型实际映射为1：1（其中查询返回一个DTO，其中包含视图的所有数据）。从技术上讲，这暴露了我们领域的一部分（读取模型-尽管以DTO形式返回）。在这种情况下，这似乎就是我们想要的。如此紧密耦合有潜在的不利影响吗？
就命令而言，我一直在考虑类似的方法：https://www.slideshare.net/fatmuemoo/cqrs-api-v2。有一张幻灯片指示命令不是头等公民。 （请参阅幻灯片26）。通过扩展，我是否正确假设我的查询返回的DTO始终是头等公民，然后他们将公开可以在该屏幕上执行的命令？
谢谢
如此紧密耦合是否有潜在的负面影响？
在理解依赖关系的方向时，需要多加注意。
特别是，如果您试图与您无法控制的客户端集成，那么您将要就不能单方面更改的合同（消息语义和模式）达成一致。
这意味着表示形式是相对固定的，但是您在实现该表示形式的方式方面有很多自由。您向客户保证他们可以得到报告12345的表示形式，并且它将具有一些方便的信息布局。但是，该表示形式是您按需生成的还是缓存的，以及如何构建它完全取决于您。
在此级别上，您并没有真正将客户与域模型耦合；您正在将它们耦合到您的视图/报告，也就是说与您的[[data模型。而且，在CQRS世界中，这种耦合是与读取模型有关，而不是正确的模型。
就命令而言，我一直在考虑类似...的方法
[我要轻轻地建议作者在2015年对当今的REST没有特别好的了解。
这里的基本问题是作者不认识到
caching
是REST constraint；并且我们HTTP协议的设计需要考虑通用组件如何理解cache invalidation。通常，对于命令（此处是“旨在更改资源表示的消息”），通常希望HTTP请求的target-uri与要更改的主要资源的标识符相匹配。POST /foo/123/command
从高速缓存失效的角度来看，这不是特别有用，如果没有人发送GET /foo/123/command请求。