聚集事件来源模式

Question

我将脚步放在事件源模式上并试图弄清聚合的含义。我读过一些博客，现在我比以往任何时候都更加困惑。

根据我的推断，聚合应该以某种方式使用户能够在事件存储上运行不同的查询，以检索不同的事件流。

用例：

1. 我想在发票上重播事件，我想查看特定员工在余额上执行的所有操作。

2. 我想重播发票上的所有事件

我希望这些是有效的用例。

活动商店：

| event_id | invoice_id | EmployeeId | Event            | Payload |
|----------|------------|------------|------------------|---------|
| 1        | 12345      | 12345      | Invoice_InReview | JSON    |
| 2        | 12345      | 12345      | Invoice_Billed   | JSON    |
| 3        | 12345      | 45567      | Invoice_Paid     | JSON    |
| 4        | 12345      | 77341      | Invoice_Reversed | JSON    |
| 5        | 12345      | 98421      | Invoice_Paid     | JSON    |

JSON包含有关付款更改，发票调整和发票状态的信息。状态为（审核，开票，已付款）

因此，根据我的理解，需要5个组成部分。

1. 事件-特定事件。
2. 事件源-调用回购以获取相关事件的服务
3. 事件流-事件列表
4. 命令-发票上的请求操作
5. 聚合-确定加载事件的输入的api

我了解其他因素的作用，但是很难将自己的头围在Aggregate上。它是什么 ？

请问我有两个综合课程吗

• 通过发票汇总事件
• AggregateEventsByInvoiceEmployee

我确实很难弄清楚骨料的需要和用途。我看到的所有示例都使用UUID，这对我来说根本没有意义？任何帮助将不胜感激。

Answer 1

我将脚步放在事件源模式上并试图弄清聚合的含义。我读过一些博客，现在我比以往任何时候都更加困惑。

那不是你的错

聚合的概念来自Eric Evans对域建模的描述。

在典型的部署中，我们有一个数据库，其中包含要跟踪的所有事实。我们有一个模型，其中这些事实会随着时间而改变。我们要确保我们正确地跟踪这些更改，这意味着不会引入不一致之处。

对此的粗略回答是，我们将数据库置于域模型的后面，该域模型包含有关如何允许更改数据库中数据的所有规则。在Evans时代，域模型是位于应用程序层和持久性层之间的一层。如今，您更可能听到的是“组件”或“模块”，而不是层，但角色并没有太大变化：保护数据库免受不正确的更改。

如果我们仔细检查域，我们通常会在模型集群中发现表现出有趣特性的数据：改变集群状态的规则并不取决于集群外部的任何信息。

示例：在交易应用程序中，对某些商品的出价和报价进行匹配和处理。但是，匹配一种商品（黄金）的规则完全独立于与另一种商品（冷冻浓缩橙汁）相关的数据。您无需了解FCOJ中发生的任何事情就可以正确处理黄金交易中的活动，反之亦然。

这些群集（可以单独考虑）是集合。

隔离的两个关键属性是

• 集合内部状态的更改不依赖于集合外部的更改
• 集合外部进行的更改不依赖于集合内部进行的更改

因此，在此示例中，我们可能有一个针对Gold的TradeBook“聚合”，以及一个针对FCOJ的TradeBook“聚合”。要处理订单，您需要加载所需的集合，将更改应用到该集合并保存，而无需彼此联系。

请问我有两个综合课程吗

• 通过发票汇总事件
• AggregateEventsByInvoiceEmployee

不，您可能基于相同的事件历史记录有两个视图或投影。

更准确地说，在Evans描述的体系结构中，将有一个“聚合根”，并且您的每个用例在API中都会对该聚合使用不同的查询。

但是最近，这种做法是要认识到，读取用例不需要与写入用例相同的约束。因此，今天您更有可能看到每种用例的视图（或投影），其中每种用例的内存表示都是根据数据存储中记录的事件构建的。

因此，我所理解的是一种汇总，本质上是可以唯一标识与单个实例相关的所有事件（在我的情况下为发票）的任何事物。因此，就我而言，invoiceId是否可以视为汇总？

否。在您的情况下，发票可能是汇总的。

更准确地说，您的域模型大概是在协调每个发票的余额，调整，状态和付款之间的更改；这些值是我之前谈论的那种集群的一个例子。您可以更改这些值，而不必考虑例如Invoice [67890]的调整。

因此，我所理解的是一种汇总，本质上是可以唯一标识与单个实例相关的所有事件（在我的情况下为发票）的任何事物。

问题在于这种理解与现有文献不太吻合，并且可能导致混乱的沟通。

在文档存储或键值存储中，聚合类似于文档，而不是用于查找文档的键。在RDBMS中，聚合将是相关实体，而ID将是您用于加载实体的主键。在事件存储中，流的内容描述的是聚合中事件的更改，ID只是用于查找正确事件的键。

事件存储可以包含非聚合ID的其他列吗？

当然-您可以在事件中存储所需的任何元数据。创建其他列可以提高查询性能，使其更容易分片数据，等等。

我们可以尝试从事件存储中加载对该列进行查询的事件，并对其进行汇总吗？（发票ID，员工ID）在这种情况下。

当然，您可以按自己喜欢的任何方式查询事件。

最好不要通过重放任意事件来恢复域模型的当前状态。

在您的示例中，[1,2,3,4,5]一起发生的事件说明了有关发票的连贯故事。但是，仅凭事件[4]本身来尝试了解发票可能并不能助您一臂之力。

请记住，事件通常不是更改后模型状态的完整表示，而是更改内容的描述。考虑“补丁”，而不是“快照”。