java - 聚集事件来源模式

Question

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

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

用例:

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

我想重播发票

上的所有事件

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

Activity 商店:

| 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个组成部分。

事件-特定事件。

事件源-调用repo以获取相关事件的服务

事件流-事件

的列表

命令-对发票

的请求操作

Aggregate-确定输入以加载事件的api

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

请问我有两个综合类(class)吗

AggregateEventsByInvoice

AggregateEventsByInvoiceEmployee

我真的很难弄清楚骨料的需要和用途。我看过的所有示例都使用UUID，这对我完全没有意义？任何帮助将不胜感激。

Answer 1

I am dipping my feet into event sourcing pattern and trying to make sense of aggregates.I have read a few blogs and now I am more confused than ever before.

那不是你的错
聚合的概念来自Eric Evans对域建模的描述。
在典型的部署中，我们有一个数据库，其中包含要跟踪的所有事实。我们有一个模型，其中这些事实会随着时间而改变。我们想要确保我们正确地跟踪这些更改，这意味着不会引入不一致之处。
对此的粗略回答是，我们将数据库置于域模型的后面，该域模型包含有关如何允许更改数据库中数据的所有规则。在Evans时代，域模型是位于应用程序层和持久性层之间的一层。如今，您更可能听到的是“组件”或“模块”，而不是层，但是角色并没有太大变化:保护数据库免受不正确的更改。
如果仔细检查域，我们通常会在模型集群中发现具有有趣特性的数据:更改集群状态的规则并不取决于集群外部的任何信息。
示例:在交易应用程序中，对某些商品的出价和报价进行匹配和处理。但是，匹配一种商品(黄金)的规则完全独立于与另一种商品(冷冻浓缩橙汁)相关的数据。您无需了解FCOJ中发生的任何事情就可以正确处理黄金交易中的 Activity ，反之亦然。
这些群集(可以单独考虑)是聚合。
隔离的两个关键属性是

聚合内部状态的

更改不依赖于聚合

外部的更改
聚合外部进行的

更改不依赖于聚合

内部进行的更改

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

Will I have two aggregate classes

• AggregateEventsByInvoice
• AggregateEventsByInvoiceEmployee

不，根据相同的事件历史记录，您可能会有两个 View 或投影。
更确切地说，在Evans描述的架构中，将有一个
“聚合根”，您的每个用例在API中都会针对该聚合使用不同的查询。
但是最近，实践是认识到读取用例不需要与写入用例相同的约束。因此，今天您更有可能看到每种用例的 View (或投影)，其中每种用例的内存表示都是根据数据存储中记录的事件构建的。

so what I understand is an aggregate is essentially anything that can uniquely identify all events related to single instance (in my case invoice). So in my case can the invoiceId be considered as an aggregate?

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

so what I understand is an aggregate is essentially anything that can uniquely identify all events related to single instance (in my case invoice).

问题在于这种理解与现有文献不太吻合，并且可能导致困惑的沟通。
在文档存储或键值存储中，聚合类似于文档，而不是用于查找文档的键。在RDBMS中，聚合将是相关实体，而ID将是您用来加载实体的主键。在事件存储中，流的内容描述的是聚合中事件的更改，ID只是用于查找正确事件的键。

Is it okay for event store to have additional columns that are not aggregate id

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

Is it okay for us to try to load events from event store that query on columns in addition to aggregate it ? (invoice id , employee id) in this case.

当然，您可以按自己喜欢的任何方式查询事件。
最好不要通过重放任意事件来恢复域模型的当前状态。
在您的示例中，事件 [1,2,3,4,5]一起讲述了有关发票的连贯故事。但是，仅凭事件 [4]尝试对发票有所了解可能无法帮助您。
请记住，事件通常不是更改后模型状态的完整表示，而是更改内容的描述。考虑“补丁”，而不是“快照”。