cqrs与cqs之间的差异

Question

我正在学习什么是 CQRS 模式，并且知道还有 CQS 模式

当我尝试搜索时，我在 CQRS 上发现了很多图表，信息，但却发现了很多关于的信息。 CQS

  

CQRS 模式中的关键点

在cqrs中有要编写的一个模型（命令模型）和要读取的一个模型（查询模型），完全独立 。

CQS 如何与 CQRS 区分开来。 。 ？

关键点是什么，两者都有区别。 。 ？

任何帮助将不胜感激：）

Answer 1

CQS（命令查询分离）和CQRS（命令查询责任分离）非常相关。您可以将CQS视为类或组件级别，而CQRS更多地处于有界上下文级别。

我倾向于认为CQS处于微观层面，而CQRS处于宏观层面。

CQS规定了用于查询或写入模型的单独方法：查询不会改变状态，而命令会改变状态但没有返回值。它由Bertrand Meyer设计，作为他在Eiffel编程语言方面开创性工作的一部分。

CQRS规定了类似的方法，除了它更多的是通过您的系统的路径。查询请求从命令获取单独的路径。查询返回数据而不改变底层系统;该命令改变了系统，但没有返回数据。

Greg Young汇总了几年前CQRS的pretty thorough write-up，并探讨了CQRS如何成为CQS的演变。几年前这份文件向我介绍了CQRS，我发现它仍然是一个非常有用的参考文档。

Answer 2

最大的区别是CQRS使用单独的数据存储来执行命令和查询。查询存储可以使用不同的技术（如文档数据库），也可以只是同一数据库中的非规范化模式，这样可以更轻松地查询数据。

数据库之间的数据通常使用类似服务总线的方式异步复制。因此，查询存储中的数据最终是一致的（将在某个时间点存在）。应用程序需要考虑到这一点。虽然可以使用相同的事务（相同的数据库或两阶段提交）在两个存储中写入，但通常不建议出于可伸缩性的原因。

CQS架构从相同的数据存储/表中读取和写入。

Answer 3

This is an old question but I am going to take a shot at answering it. I do not often answer questions on StackOverflow so please forgive me if I do something outside the bounds of community in terms of linking to things, writing a long answer, etc.

There are many differences between CQRS and CQS however CQRS uses CQS inside of its definition! Let's start with defining the two and then we can discuss differences.

CQS defines two types of messages depending on their return value. No return value (void) specifies this is a Command. A return value (non-void) specifies this method is a Query.

Commands change information Queries return information

Commands change state. Queries do not.

Now for CQRS which uses the same definition as CQS for Commands and Queries. What CQRS says is that we do not want one object with Command and Query methods. Instead we want two objects, one with all the Commands and one with all the Queries.

The idea overall is very simple its everything after doing this where things become interesting. There are a large number of talks online of me discussing some of the attributes associated (sorry way to much to type here!)

Answer 4

• CQS与命令和查询有关。它不在乎模型。您以某种方式分离了仅读取数据的服务和修改数据的服务。
• CQRS关于写和读的单独模型。当然，使用写入模型通常会读取一些内容来满足业务逻辑，但是您只能对读取模型进行读取。单独的数据库是最新技术。但是，请想象一个单独的DB，它具有用于OR / M建模的单独的读写模型。通常它足够好。

我发现人们经常说他们有CQS时就会练习CQRS。

Answer 5

阅读发明家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 on Wikipedia