cqrs与cqs之间的差异
Mr *_*nch 47 command-query-separation cqrs ncqrs
我正在学习什么是CQRS模式,并且开始知道还有CQS模式
当我试图搜索时,我发现了很多图表,关于CQRS的信息但是没有发现很多关于CQS的信息
CQRS模式的关键点
在cqrs中,有一个要编写的模型(命令模型)和一个要读取的模型(查询模型),它们是完全独立的.
CQS如何与CQRS区分开来..？
两者都有区别的关键点是什么..？
任何援助将不胜感激 :)
Dav*_*ter 57
CQS(命令查询分离)和CQRS(命令查询责任分离)是非常相关的.您可以将CQS视为属于类或组件级别,而CQRS更多地处于有界上下文级别.
我倾向于认为CQS处于微观层面,而CQRS处于宏观层面.
CQS规定了用于查询或写入模型的单独方法:查询不会改变状态,而命令会改变状态但没有返回值.它由Bertrand Meyer设计,作为他在Eiffel编程语言方面的开创性工作的一部分.
CQRS规定了类似的方法,除了它更多的是通过您的系统的路径.查询请求从命令获取单独的路径.查询返回数据而不改变底层系统; 该命令改变系统但不返回数据.
Greg Young的组建了一个非常完善的写了什么CQRS是几年前,并进入CQRS是如何CQS的演变.几年前,本文档向我介绍了CQRS,我发现它仍然是一个非常有用的参考文档.
Tom*_*cki 11
- CQS是关于命令和查询的。它不关心模型。您以某种方式将读取数据的服务和其他写入数据的服务分开。
- CQRS是关于单独的写入和读取模型。当然，写模型的使用往往需要读一些东西来完成业务逻辑，但你只能在读模型上做读。单独的数据库是最先进的。但是想象一下单个 DB 具有在 ORM 中建模的用于读取和写入的单独模型。它通常已经足够好了。
我发现人们经常说当他们有 CQRS 时他们会练习 CQRS。
最大的区别是 CQRS 使用单独的数据存储来存储命令和查询。查询存储可以使用不同的技术，如文档数据库，或者只是同一数据库中的非规范化模式，使查询数据更容易。
数据库之间的数据通常使用服务总线之类的东西异步复制。因此，查询存储中的数据最终是一致的（将在某个时间点存在）。应用程序需要考虑到这一点。虽然可以使用相同的事务（相同的数据库或两阶段提交）在两个存储中写入，但出于可伸缩性原因，通常不建议这样做。
CQS 架构从相同的数据存储/表中读取和写入。
- 为免生疑问 - CQRS 在应用时，*允许*您使用单独的数据存储，但这不是必需的。您仍然可以使用一个数据存储“执行 CQRS”。 (12认同)
阅读发明家 Greg Young 的回答
我认为，就像“依赖注入”一样，这些概念是如此简单和理所当然，以至于它们具有奇特的名称这一事实似乎促使人们认为它们比实际情况更重要，尤其是因为 CQRS 经常与事件溯源一起被引用。
CQS 是读取改变状态的方法的分离；不要在一个方法中同时进行。这是微观层面。
CQRS 将这个概念扩展到了机器-机器 API 的更高级别，消息模型和处理路径的分离。
因此，CQRS 是您应用于 API 或 Facade 中的代码的原则。
我发现 CQRS 本质上是 SOLID 中的一个非常强大的 S，将这种分离深深地推向了开发人员的心灵，以生成更易于维护的代码。
我认为 Web 应用程序不适合 CQRS，因为通过表示传输的状态突变意味着命令和查询是同一请求-响应的两侧。表示是命令，响应是查询。
例如，您发送订单并接收所有订单的视图。
想象一下，如果一个网站的代码被分解为命令端和查询端。路由操作处理代码需要属于这些方面之一，但它同时兼顾了这两个方面。
想象一个更强的隔离，如果代码被移到两个不同的可编译代码库中，那么网站将接受表单的 POST，但用户将不得不浏览到另一个网站 URL 以查看操作的影响。这显然是疯狂的。一种解决方法是始终重定向，尽管这并不是真正的 RESTful，因为理想的 REST 应用程序是下一个表示包含超文本以驱动下一个状态转换等等。
鉴于网站是人与机器（或机器与机器）之间的 REST API，这也包括 REST API，尽管其他类型的 HTTP 消息传递 API 可能非常适合 CQRS。
网站边界内的服务或外观显然可以与 CQRS 配合使用，尽管动作处理程序将位于此边界之外。
请参阅维基百科上的 CQS
- 我只是偶然发现这个，想补充一点。您提到“我认为 Web 应用程序不适合 CQRS，因为通过表示传输进行的状态突变意味着命令和查询是同一请求响应的两侧。表示是命令，响应是查询。” 这其实是一个常见的说法！但我想问一下，你有没有看过原子源是如何工作的？与原子提要类似，可以表示多少条数据？ (2认同)
- 这里已经有一两个链接链接了我关于这个主题的材料，这就是为什么我没有[不得不剪断]“想象一个更强大的隔离，如果代码被移到两个不同的可编译代码库中......”这更像是一个REST 问题而不是说 CQRS。没有说明数据是如何处理的。POST 可用于创建事件 /streams/{stream} 似乎是一个可能的目标（您同意吗？）。GET 可能会转到 /streams/{stream} 以获取信息。没有任何内容指定对该资源的所有请求必须由相同的服务等处理。 (2认同)
- 如果不清楚（抱歉，简短的评论），POST 返回 URI 的情况也很常见，然后客户端应该针对最新状态 * 或 * 发出 GET 通知（想想异步过程） (2认同)
这是一个古老的问题，但我要回答一下。我不经常在StackOverflow上回答问题，所以如果我在社区范围之外做一些事情，例如链接到事物，写长答案等，请原谅我。
CQRS和CQS之间有很多区别，但是CQRS 在其定义内使用 CQS！让我们先定义两者，然后讨论差异。
CQS根据消息的返回值定义了两种类型的消息：没有返回值（void）指定这是一条命令；返回值（非void）指定此方法为查询。
- 命令更改信息
- 查询返回信息
命令更改状态。查询不。
现在是CQRS，它使用与“命令和查询”的CQS相同的定义。CQRS所说的是我们不希望使用Command和Query方法的对象。相反，我们需要两个对象：一个包含所有命令，一个包含所有查询。
总的来说，这个想法很简单。这一切后，这样做，事情变得有趣。在线上有很多演讲，我讨论了一些相关的属性（很抱歉，此处无法键入！）。
- 我认为这个答案没有用。这个“一个物体”或“两个物体”是什么？我认为这并不清楚。CQRS 是一种架构模式，而 CQS 更像是一种设计模式。完全真实的 CQRS 的查询完全与命令分开（例如 2 个不同的项目）。 (2认同)