在均匀采购模式中处理状态更新答案

【问题标题】：Handle Status Update In Even Sourcing Pattern在均匀采购模式中处理状态更新
【发布时间】：2018-04-20 15:13:08
【问题描述】：

我正在寻找一种审计模式来保存我的实体的历史记录，我遇到了事件溯源模式。这是一种有趣的模式，其中大部分对我来说很有意义，但我有一个关于如何实现某个用例场景的问题？

用例：

生成了一张发票，金额为 100 美元，状态为审核中。
然后发票状态更新为 billed
然后支付 50 美元，调整为 20 美元，状态更新为已付款
我们后来意识到金额不正确。所以我们想回滚之前的交易并将账单状态恢复为再次账单
然后我们过帐 70 美元的付款和 20 美元的调整并更新发票状态以完成。

根据我对事件存储的理解。它应该只包含应用于实体的操作。因此该事件始终具有更新的交易金额（付款和调整）和状态。

数据库：

发票：

| id    | balance | payment | adjustment | status   |
|-------|---------|---------|------------|----------|
| 12345 | 10      | 70      | 20         | Paid     |

活动商店：

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

JSON 包含有关付款、调整和状态更改的信息

这是我的问题

我知道余额可以如何逆转，但我不明白我们如何才能实现相同的状态效果
此外，如果上述事件的 api 调用（命令）出现故障，我将如何处理。 IE
- 第 3 步调用服务
- 然后步骤 5
- 然后是第 4 步。

据我了解，余额可以，但发票状态不正确。

请告诉我如何最好地处理事件源模式。

【问题讨论】：

“如果事件以不同的顺序出现，我将如何处理” - 它们永远不会出现乱序，而不是在同一个 AggregateStream
您的 EventStore 不正常。它还应该包含事件的类型。事实上，它应该允许附加任何类型的事件。
@ConstantinGalbenu 事件出现故障我的意思是对服务的 api 调用出现故障，即 api 要求付款，然后是另一笔付款，然后撤销第一次付款。为了清楚起见，我将添加事件列
“事件”是指“命令”？
您的 EventStore 应该有仅这些列：event_id, invoice_id, event_type, event_payload。您删除了 payment、adjustment 和 status 列。事件属性以适合您的格式（即 json）在 event_payload 列中序列化。因此，当命令到达您的 Invoice 时，您加载所有事件，反序列化它们并将它们应用到 Invoice 实体。 Invoice 建立其内部状态（total_amount 和status），然后处理命令。因此，状态不是保存在 EventStore 中，而是保存在内存中。

标签： java microservices event-sourcing

【解决方案1】：

我知道如何平衡余额，但我不明白我们如何才能实现相同的状态效果

因此，首先要做的是与您的领域专家核对，以了解通用语言是否具有撤销和还款之间发票状态的概念。

根据我在此处看到的情况，我预计会自行逆转以再次将状态置于计费状态。我们认为它是付费的，但该条目是错误的，因此我们会将对象恢复到之前的状态。

如果那是正确的，那么我们在那里的状态将是Billed。

但它可能不是——这不是撤消，而是您域内的行为。这可能会将域移动到状态机中以前未被发现的部分。

如果上述事件的 api 调用（命令）出现故障，我将如何处理。

这里可能隐藏了两个不同的问题 - 我将分别总结一下。

如果您担心下游消费者对事件的反应，那么设计您的消费者非常重要——如果他们需要了解整个历史，那么他们会从历史中读取。对历史变化做出反应的消费者将从事件存储中读取有序的历史，而不是对出现在消息传输中的消息做出反应。换句话说，发布的事件就像一个通知，告诉消费者刷新它的历史副本。

如果你担心如果命令出现乱序会得到“错误”的历史记录，那么你需要复习和整合 Udi Dahan 的文章 Race Conditions Don't Exist

时间上的微秒差异不应影响核心业务行为。

【讨论】：