在活动中如何应对生产失败？
因此，假设我想使用事件驱动的体系结构使用 event-sourcing 建立电子商务系统。假设用户想购买产品，其价格为1 $，，但我想念计算，它变成了2美元。现在，用户将因钱包而不是1美元而损失2美元。因此，如果是 crud ，我只需修复错误并连接到数据库主机并修复用户钱包（也让他道歉）。但是，据我所知，在事件来源中，我们不应编辑或删除事件（仅附加），因为它是单一的真实来源。那么我应该如何处理这种失败呢？我可以想到的一件事是创建一个可以发布任何类型的事件并这样修复的管理页面。
AccountCreatedEvent {userId：1，balance：3}
ProductPurchasedEvent {用户ID：1，价格：2} // ** MISS计算价格应为1 $
存款moneyevent {userId：1，金额：1} //通过管理员手动修复
我似乎很奇怪，但是如果我真正必须修复错误并有效数据，该怎么办事件来源
So suppose I want to make an e-commerce system using Event-driven architecture with Event-sourcing. Let's say the user want to buy a product and its price is 1$, but I miss calculate and it becomes 2$. Now the user would lose 2$ from his wallet instead of 1$. So if it was CRUD I could just simply fix the bug and connect to the database host and fix the user wallet (also give him some apologize). but in event-sourcing, as far as I know, we should not edit or delete event (only append) since it's single source of truth. So how should I deal with this kind of failure? One thing I can think of that's to create an admin page which can publish any kind of events and fix it like this.
AccountCreatedEvent { userId: 1, balance: 3 }
ProductPurchasedEvent { userId: 1, price: 2 } // **miss calculate price should be 1$
DepositMoneyEvent { userId: 1, amount: 1 } // manually fixed by admin
I know it seems weird, but what if I really have to fix the bug and also valid the data how do we achieve that in event-sourcing
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一个常见的答案是您看域。例如，存在哪些业务流程来减轻客户收取的应急情况？
我们的业务有退款流程吗？
“正确”的答案是实施该过程。由此产生的历史记录看起来像是向客户收取费用的事件，后来是另一个退款金额以使事情正确的事件。
当然，这是您的修复并道歉方法；主要区别在于，我们将误差校正视为系统的一部分，而不是我们即兴创作。
记忆，猜测和道歉（Pat Helland，2007年）是一个很好的起点。
另一个示例是系统做正确的事情，但写下错误的信息的错误。这里的一个常见模式是处理此错误，以在会计中犯下的方式 - 生成事件来“逆转”转录错误，并创建了一个新事件来介绍正确的会计。
同样，请注意，此校正过程是会计领域的一部分。我们的工作是忠实地重新创建已经存在的错误纠正过程。
整个基本模式都是相同的。我们在系统中添加了更多事件，以纠正错误（以及更多的事件以纠正校正中的错误；它一直是海龟）。
当您获得流中出现的事件触发的流程时，您可能最终会播放“追逐”。
我们向客户收费过高，但这意味着客户会自动加入VIP折扣计划。当我们解决错误时，我们还需要删除其VIP状态吗？他们在发现错误之前进行的折扣购买会发生什么？
A common answer is that you look to the domain. For example, what business processes exist to mitigate the contingency that a customer is over charged?
Does our business have a process for refunds?
The "right" answer is to implement that process. The resulting history will look like an event that over charges the customer, and later another event that refunds the overcharged amount to make things right.
This is, of course, exactly your fix it and apologize approach; the main difference being that we treat the error correction as part of the system, rather than being something we improvise.
Memories, Guesses, and Apologies (Pat Helland, 2007) is a good starting point.
Another example would be a fault where the system did the right thing, but wrote down the wrong information. A common pattern here is to process this mistake the way it would be done in accounting - an event is produced to "reverse" the transcription error, and a new event is created to introduce the correct accounting.
Again, notice that this correction process is part of the domain of accounting. Our job here is to faithfully re-create the error correcting processes that already exist.
The basic pattern is the same throughout; we add more events to the system to correct the mistakes (and more events to correct mistakes in the corrections; it's turtles all the way down).
When you've got processes that are triggered by the events that appear in the stream, you may end up playing "chase".
We overcharged the customer, but this meant that the customer was automatically enrolled in the VIP discount program. When we fix the error, do we also need to remove their VIP status? What happens to the discounted purchases they made before the error was discovered?