事件源整个系统坏了答案

【问题标题】：Event source the whole system is bad事件源整个系统坏了
【发布时间】：2019-11-15 15:32:07
【问题描述】：

我正在学习使用 CQRS、MassTransit 和用于读取端的不同类型存储的适当微服务架构。 CQRS 经常出现的一件事是事件溯源。我明白这根本不是强制性的。但是，我想不出为什么在整个系统上使用它真的是一种反模式。

对我来说，问题更像是不从事件溯源开始（并且仍然有单独的数据存储，具体取决于微服务。例如：elasticsearch、mongodb 等）并在需要时迁移/配置或另一方面，从事件溯源开始，这样您以后就不必处理迁移。

【问题讨论】：

对于像这样的辩论问题，DDD-CQRS-ES slack 是最好的选择 - 这是一个微妙的东西，可以从不同的角度来回受益，即不可能没有官方最佳实践。这条反模式格言是 80/20 规则的经验法则——事件采购您的核心域比其他任何东西都更划算。

【解决方案1】：

我想不出为什么在整个系统上使用它真的是一种反模式。

我同意——称其为“反模式”是夸大其词。

我相信的拼写？在整个系统上使用事件溯源今天并不划算。

这可能是明天，因为我们得到了更多的实践，设计这些系统的成本下降了，我们学会了从中获取更多的好处。

同时 - 您从事件溯源中获得的时间查询有多大价值？在您获得竞争优势的核心领域，它们可能非常有价值。在您只是对外界提供给您的信息进行簿记的地方？没那么多 - 您可能会从仅跟踪“现在”的更简单的解决方案中获得所需的一切。

【讨论】：

我在这里可能太天真了。与其考虑未来，不如考虑在开始一个项目时“正确”做事或在此过程中改变它之间更容易的是什么。对我来说，正确地做这件事感觉更容易（比如使用微服务和 cqrs 而不是单体），而不是在未来改变……当开始一个项目时，我相信范围会很小……
拥有事件历史记录是事件溯源的一大优势。但另一个事实是，您不依赖供应商或任何类型的存储，因为您可以从事件存储中配置任何存储。例如，如果您从 dynamodb 更改为 cosmosdb，那么您就没有那么多问题了……您只有电子商务平台的文档存储并且您需要 graphdb？没问题，您可以使用您的事件存储来配置它。我对单一事实来源的真正担心是它是单点故障并且不可扩展

【解决方案2】：

我最近就这个问题发表了blog post。它解释了为什么事件溯源是一种持久性策略，不应该在全球范围内使用。

总结一下：事件溯源强制您为每个更改的数据发出一个事件。这可能导致非常细粒度的事件。如果您使用事件溯源进行微服务间通信，您会将这些事件暴露给外部世界。

最后，您公开了您的持久层，类似于在基于 CRUD 的持久性策略中公开您的（关系）数据库架构。

【讨论】：

我想我明白你在说什么。我喜欢拥有单一事件存储的方法是……嗯，它是单一的事实来源。如果我想构建使用 ElasticSearch 和 Nosql 存储，我只需要一个新的投影。但据我了解，在您的架构中，您会有多个事实来源吗？每个有界上下文 1 个？不过我明白了，这也很好。
“搜索”可能是一个有界上下文，它从其他上下文请求一些数据。所以一种解决方案是“搜索”指定它需要什么，而有界上下文会公开这些数据。
事件溯源不关心微服务间的通信。领域事件和集成事件不能混用，应该分开实现。