java - 事件溯源中的乐观锁机制 "UNDO"流程

Question

我一直在问很多有关事件溯源的问题，因此对此表示歉意，但我想从一开始就解决这个问题。

设置

| p_key | invoice_id | EmployeeId | Event type        | Version | Data |
|-------|------------|------------|-------------------|---------|------|
| 1     | 12345      | E456       | Invoice_Generated | 1       | JSON |
| 2     | 12345      | E567       | Invoice_Reviewed  | 2       | JSON |
| 3     | 12345      | E456       | Invoice_Paid      | 3       | JSON |
| 4     | 12345      | E142       | Invoice_Comment   | 4       | JSON |
| 5     | 12345      | E412       | Invoice_Comment   | 5       | JSON |
| 6     | 12346      | E999       | Invoice_Paid      | 7       | JSON |
| 7     | 12345      | E456       | Invoice_Refunded  | 8       | JSON |

我假设发票Id是聚合的。由于每次对发票进行更改时版本号都会增加。

用例:

事件存储包含发票上应用的所有事件，还包含有关哪个员工应用它的信息。在当前场景中，发票被生成、审核、支付。有人注意到一些问题发表了一些评论，然后我们决定在退还旧付款之前发布新付款[正在撤消的事件在历史上较早]。

API 调用:

退款/发票/{invoiceid}/{employeeid}

事物的流动

选项1

• 检索给定发票的所有事件
• 将所有事件保存在事件流中并保存最新版本。
• 循环遍历所有事件以查找所需的事件实例。
• 对该事件应用“撤消”操作并为其指定版本号(最新+1)
• 调用数据库来检查事件存储中的最新版本。验证它与 Event Stream 中保存的相同。
• 确保新事件大于流中的上一个版本。我们假设它也是“DO ACTION”的更高版本。

问题

• 每次检索并保存应用程序中的所有事件可能会变得非常昂贵。
• 光是“撤消”操作就需要做大量工作。

选项 2:

• 我对数据库进行了 2 次调用
  1. 根据发票 ID 和员工 ID 调用以获取事件
  2. 调用获取发票上应用的上次事件的最新版本。
• 根据事件中的数据撤消更改
• 创建一个版本号大于最新版本的“UNDO”事件。
• 再次调用数据库以再次获取最新版本。
• 确保“UNDO”版本比最新版本恰好大 1

问题

不确定这是否正确。我们是否应该多次将内容添加到事件流中。

还可以查询事件数据库两次，一次仅使用发票 ID，一次使用发票 ID 和员工 ID

如果我遗漏了某些内容，或者我的版本样式错误，或者我对聚合的假设错误，请告诉我。

Answer 1

我建议您清楚一些要点。

无论您对域模型进行什么更改，您可能都希望使用相同的管道；无论是处理新命令，还是撤消先前的命令，实际的机制都应该以相同的方式处理。

如果您需要“撤消”，那么您的域模型应该了解如何执行此操作，并且您保存在内存中的数据的形状应该支持这些功能。因此，如果您正在设计一个发票模型，允许您查询其历史记录中的特定事件，那么您的内存表示应该允许您访问这些事件。

性能优化的第一条规则是“不要”，但如果您担心从数据库读取数据的成本，您可以缓存模型的热表示。

如果您试图找出关系数据库中的乐观写入，Jonathan Oliver是一个很好的起点。