我正在使用CQRS，MassTransit和用于读取侧的不同类型的存储来学习适当的微服务体系结构。 CQRS经常出现的一件事是事件源。我确实知道这不是强制性的。但是，我想不出为什么在整个系统上使用它实际上是一种反模式。
对我来说，问题更像是更容易地从事件源开始（并且仍然具有独立的数据存储，具体取决于哪个微服务，例如：Elasticsearch，mongodb等），并在需要或需要时进行迁移/配置另一方面，从事件源开始一切，这样您以后就不必再处理迁移了。
答案 0 :(得分：1)
我想不出为什么在整个系统上使用它真的是一种反模式。
我同意-称其为“反模式”是一种夸大其词。
我相信拼写吗？在整个系统上使用事件来源今天并不划算。
可能是明天，因为我们将进行更多实践，而设计这些系统的成本将下降，我们将学习从中受益更多。
同时，您从事件来源获得的时间查询的价值是多少？在您获得竞争优势的核心领域中，它们可能会非常有价值。在您只是对外部世界提供的信息进行簿记的地方？没那么多-您可能会从仅跟踪“现在”的简单解决方案中获得所需的一切。
答案 1 :(得分：0)
我最近发布了关于此问题的blog post。它解释了为什么事件源是一种持久性策略，并且不应该在全球范围内使用。
总结一下：事件源迫使您为每个更改的数据发出一个事件。这会导致非常细粒度的事件。如果您使用事件源进行微服务之间的通信，则将那些事件暴露给外界。
最后，您公开了您的持久性层，这与在基于CRUD的持久性策略中公开（关系）数据库模式相当。