Java CQR与事件源差异

CQR（命令查询责任分离）和事件源之间的区别是什么

我相信活动采购是一种CQR。是什么区别了它们，是什么使事件来源不同于其他类型的CQR

谢谢，

CQRS CQRS由Greg Young介绍

CQRS只是在以前只有一个对象的情况下创建两个对象。根据方法是命令还是查询进行分离（Meyer在命令和查询分离中使用的定义相同，命令是任何改变状态的方法，查询是任何返回值的方法）

通常，这意味着每个对象都将使用不同的数据表示形式，以便适合该用途。这里的通用语言是指“写模型”和“读模型”。通常情况下，首先对写模型进行更改，然后异步传播到读模型

碰巧，数字“2”没有什么神奇之处；你可以很容易地得到三种不同的表示法

这里的主要好处是，您可以独立地调整读用例和写用例的数据结构

活动来源 事件源以非破坏性方式记录状态的模式。国家的每一次变化都是如此。因为这些更改是非破坏性的，所以我们保留了在对象生命周期的任何时刻回答有关对象状态的查询的能力

使用事件可以更有效地使用存储空间（相对于存储每次更改后状态的完整表示），同时保留更改的语义意图（相对于仅存储差异）

Greg这样描述事件源

将当前状态存储为一系列事件，并通过重播该系列事件在系统内重建状态

CQRS+事件源 这些技术经常配对在一起，因为日志作为概念数据结构，在支持查询方面不是特别有效。通常，您会希望将日志压缩为更适合读取（可能比写入更频繁）的其他表示形式

因此，在CQRS模式中，我们通常使用日志作为持久性模型，然后从该日志创建对象的查询适当表示，并缓存这些表示，以便能够快速支持查询（接受折衷意见，即查询中使用的表示并不总是反映可用的绝对最新信息）。

CQRS: CQRS代表命令查询责任分离。由Greg Young引入。每个方法都应该是执行操作的命令或返回数据的查询。命令不能返回数据，查询不能更改数据。每个模型都可以针对特定上下文进行优化，并且还保留其概念完整性

活动来源： CQR不需要事件源。您可以将事件源和CQR结合起来。这种结合可以使我们找到一种新类型的CQR。它涉及将应用程序所做的状态更改建模为不可变的序列或事件日志。您可能会考虑在系统中记录和事件日志，但老实说，事件日志记录不是事件源。事件源强制从历史中派生当前状态。如果无法从历史中推断当前系统，则不进行事件源。事实上，事件是业务事实

在域驱动的设计中，事件必须遵循普遍存在的语言，并且系统中的所有事件都必须是过去式，并且以过去式命名。事件是独立的，我的意思是事件应该有足够的数据来描述其自身

---

事件源越来越受欢迎。因为它使故障排除变得更容易，并且具有更好的性能特征；写入和读取可以独立扩展。指掌握事件源，支持松散耦合的应用程序体系结构。此外，它还可以在将来添加更多需要处理同一事件的应用程序，但c创建不同的物化视图。

让我们以一个简单的现实世界为例：

CQRS: 我们将使用cache/redis/elasticsearch进行读取查询，使用database/mysql/mongo进行写入查询。这正是CQRS的含义。将读取和写入逻辑分开就是CQRS

活动来源： 我们使用的所有发布/订阅模式都属于事件源。在这里，我们将消息作为一个事件发布到队列（kafka/RabbitMQ），订阅者只需订阅这些队列即可使用这些消息

CQRS+事件源： 我们只举上面的例子。 当写入模型（database/mysql/mongo）出现任何更新时，我们应该如何更新读取模型（cache/redis/elasticsearch）

---

我们可以在这里使用事件源。任何更新到数据库时，都将创建一个事件（包含更改）并将该事件推送到队列。现在是读卡器模型（elasticsearch）将订阅这些队列并在其状态之上应用事件。因此，我们在读写模型中保持了相同的状态。

简单明了的解释，谢谢@lokanadham100