“事件源”是实现“命令处理程序模式”的应用程序的一个花哨名称，它保存每个成功执行的命令（SeatReserved、OrderCanceled、BlaBlaBlaDone），只执行插入（没有更新和没有删除，例如：Balance +100, Account Closed) 在数据库中，所有选择都类似于select top 1 MailAddress from UserAddressTable where UserID=@value order by lastUpdated desc 或select sum(balance) from UserTransactions where UserId=@value???
【问题讨论】：
标签： design-patterns event-sourcing
您对 Command 端提出的定义基本上是正确的。
但是，没有人说您必须将事件存储在关系数据库中。事实上，这通常是一个糟糕的选择。在处理一个简单的银行账户示例时，您可能提前知道您将需要一个余额，这意味着您可以在数据库表中维护最新的余额。
但是，在从普通银行账户示例中删除的系统中，您可能无法提前确切地了解所有事件将如何被解释。
这就是事件溯源的价值所在。您永远不会丢弃数据，因此，如果将来您意识到自己想要执行一种您从未预料到的分析，那么您可以，因为您从未删除任何数据。
当您解释事件流时，您通常会对这些事件执行fold，从而生成汇总结果。有时，出于效率原因，您提前完成，然后通常称为快照。
与事件溯源密切相关的是CQRS 的概念。
【讨论】：
事件溯源是一回事，CQRS 是另一回事。
事件溯源，基本上是持久化您的模型（Akka 演员）在您的系统中执行的所有操作，以便拥有一个无状态模型，该模型可以通过所有的补液及时给出状态那些事件。
(baskedtCreated, productAdded, productAdded, productRemoved,productAdded, baskedPayed)
所以下次如果我想知道我之前的篮子的状态是什么，系统会获取一个新的 Basket 实例，并与之前的所有事件进行再水合，最终状态为已支付的篮子。
CQRS 是命令查询职责分离，基本上它是一种架构模式，将您的 RestAPI 隔离在命令中用于写入和查询用于读取，让您有机会完全独立地扩展您的服务器。
Let´s say 4 machines for Queries(Read always is more expensive), 1 for Commands?
人们感到困惑的是，事实上 CQRS 是一种非常适用于事件溯源的模式，因为 Command(CreateBasket) 可以很好地指挥 action-event(BasketCreated)。
如果有人想在 scala 中引入事件源世界，这里我有一个非常好的开源项目 https://github.com/politrons/Scalaydrated
【讨论】：
事件溯源是关于使用过去的事件重建系统状态。
你不持久化命令（当然不禁止这样做，但它与 ES 无关）。你坚持事件。在您的示例中 SeatReserved、OrderCanceled、BlaBlaBlaDone 是事件。您可以通过读取和应用这些事件来重建“预订系统”的状态，而不是仅仅从数据库中读取当前状态。
我认为这是最基本的定义。事件溯源经常与 CQRS 等其他事物一起被提及，因为将它们结合起来通常很有意义。
如果您想了解事件溯源和 CQRS，我推荐 Greg Young 的 this 文档，他经常被提及为创造事件溯源一词的人。
另外：我建议不要阅读有关该主题的 Matin Fowlers 文章。我不敢说他错了……但这篇文章至少可能令人困惑（尤其是关于外部更新和其他事情的内容）。请注意他在开头的免责声明：“我没有时间进一步研究它们”。
【讨论】：