处理均匀采购模式中的状态更新

Question

我正在查看审核模式以保存我的实体的历史记录，并且我遇到了事件采购模式。这是一个有趣的模式，大部分都对我有意义，但我有一个关于如何实现某个用例场景的问题？

用例：

1. 生成的发票金额为100美元，状态为审核状态。
2. 然后将发票状态更新为结算
3. 然后支付50美元即调整20美元并将状态更新为付款
4. 我们后来意识到金额不正确。因此，我们希望回滚先前的交易并将帐单状态还原为再次付款
5. 然后我们发布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包含有关付款，调整和状态更改的信息

所以这是我的问题

1. 我知道如何扭转平衡，但我看不出我们如何才能为状态实现相同的效果
2. 如果api调用（命令）出现上述事件的顺序，我将如何处理。即
   • 第3步调用服务
   • 然后是第5步
   • 然后是第4步。

根据我的理解，余额会很好，但发票状态不正确。

请告诉我如何在事件采购模式中最好地处理这个问题。

Answer 1

  

我知道如何扭转平衡，但我不知道如何才能对状态

实现相同的效果

因此，首先要与您的域名专家核实，了解无处不在的语言是否具有撤销和还款之间发票状态的概念。

根据我在这里看到的情况，我预计会有一个逆转，让状态再次被计费。我们认为它已付费，但该条目是错误的，因此我们将对象恢复到之前的状态。

如果这是正确的，那么我们的状态为Billed。

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

  

如果上述事件的api调用（命令）乱序，我将如何处理。

有两个不同的问题可能隐藏在那里 - 我将总结每个问题。

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

如果你担心你得到错误的＆＃34;如果命令出现故障，那么你需要查看和整合Udi Dahan的论文Race Conditions Don't Exist

  

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