CQRS和事件采购差异

Question

CQRS(命令查询责任隔离)和事件采购有什么区别？

我相信Event Sourcing是一种CQRS.每种产品的区别是什么,以及什么使得Event Sourcing与其他类型的CQRS不同？

谢谢,

Answer 1

CQRS

CQRS由Greg Young介绍; 他在2010年的解释

CQRS只是创建两个对象,而以前只有一个对象.分离是基于方法是命令还是查询(Meyer在命令和查询分离中使用的定义相同,命令是任何改变状态的方法,查询是任何返回值的方法).

通常,这意味着每个对象将使用不同的数据表示,以便适合目的.这里的通用语言是指"写模型"和"读模型".通常情况下,首先对写入模型进行更改,然后异步传播到读取模型.

碰巧,数字"2"没有什么神奇之处; 你可以很容易地将3个不同的表示形式分成两个.

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

活动采购

事件采购用于以非破坏性方式记录状态的模式.每次状态更改都会附加到日志中.因为这些更改是非破坏性的,所以我们保留了在生命周期的任何一点回答有关对象状态的查询的能力.

事件的使用提供了更有效的存储空间使用(相对于在每次更改后存储状态的完整表示),同时保留了更改的语义意图(相对于仅存储差异)

Greg用这种方式描述了事件采购

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

CQRS +事件采购

这些技术经常配对在一起,因为作为概念数据结构的日志在支持查询方面不是特别有效.您通常希望将日志压缩为更适合读取的其他表示(可能比写入更频繁).

因此,在CQRS模式中,我们通常使用日志作为持久性模型,然后从该日志创建查询对象的合适表示,并缓存这些表示,以便可以快速支持查询(接受表示中使用的表达的折衷方案)查询并不总是反映可用的绝对最新信息).

Answer 2

让我们来看一个简单的现实世界的例子:

CQRS: 我们将使用cache/redis/elasticsearch进行读取查询,使用database/mysql/mongo进行写入查询.这就是CQRS的确切含义.分离读写逻辑是CQRS.

事件采购: 我们使用的所有发布/订阅模式都来自事件采购.在这里,我们将消息作为一个事件发布到队列(kafka/RabbitMQ),订阅者将通过订阅这些队列来消费这些消息.

CQRS +事件来源: 让我们仅举几个例子.当任何更新到Write模型(database/mysql/mongo)时,我们应该如何更新Read模型(cache/redis/elasticsearch)？

我们可以在这里使用Event Source.当任何更新到达数据库时,将创建一个事件(包含更改)并将该事件推送到队列.现在,Reader Model(elasticsearch)将订阅这些队列并在其状态之上应用事件.因此,我们在读写模型中保持相同的状态.

Answer 3

CQRS：

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

事件来源：

CQRS 不需要事件溯源。您可以结合使用事件溯源和 CQRS。这种组合可以将我们引向一种新型的 CQRS。它涉及将应用程序所做的状态更改建模为不可变的事件序列或日志。您可能会考虑登录您的系统和事件日志，但老实说，事件日志不是事件源。事件溯源强制从历史中导出当前状态。如果您无法从历史中推断出您当前的系统，那么您就不是在进行事件溯源。事实上，事件就是商业事实。

在领域驱动设计中，事件必须遵循无处不在的语言，并且您系统中的所有事件都必须是过去式并以过去时命名。事件是独立的，我的意思是事件应该有足够的数据来描述它们的自我。

事件溯源越来越受欢迎。因为它使故障排除更容易并且具有更好的性能特征；写入和读取可以独立缩放。指 GRASP 事件源启用松散耦合的应用程序架构。此外，它还可以在未来添加更多需要处理相同事件但创建不同物化视图的应用程序。