Event sourcing, CQRS with Axon Server / Framework - Event Sourcing 整个应用程序是个好主意吗？

Question

这个问题与 Axon 服务器/框架的关系非常松散，因为我在学习并尝试学习如何构建微服务时专门学习它。由于没有实际动手经验很难了解所有架构模式（并且如果没有大型应用程序来实际测试/构建也很难获得动手经验），我在这里进行了很多理论化（我的问题可能只是傻傻的，对不起，我还在学习）。

我下载了 Axon Server，并在三个独立的微服务中成功构建并运行了包含的礼品卡演示。它工作得很好，我在 Axon Dashboard 上看到了事件和所有内容，但我不禁想到如果我真的构建了一个非常大的企业应用程序的“假设”。

考虑一下：

我正在构建一个像 Twitch 这样的流媒体平台。有基本的、显而易见的服务，例如带有个人资料数据的客户服务、订单服务（用于订阅、捐赠）等。

但还有其他服务，例如聊天系统。假设，我觉得事件采购聊天系统会非常有益，因为如果观众正在观看 VOD，您将拥有内置的时间戳来重播聊天。但是，我也觉得我不应该将聊天系统的事件与处理事务的事件存储混合在一起。这两个是完全独立的系统，只是将每个服务的每个事件存储在一个事件存储中感觉......单片？

我仍然不清楚最佳做法是什么。谈话中的所有示例和示例总是显示非常简单的系统，其中包含典型的 Customer、Order、Item 聚合，并且没有详细说明这个简单的应用程序如何发展为像 Twitch 这样的大型服务。

所以我的问题是，

1) 您应该事件源整个应用程序，还是可以选择哪些事件源而不是事件源？

2) Axon Server 是否支持两种不同的事件存储，例如一种用于聊天系统，一种用于其他服务？在这种情况下，我会只运行两个不同的 Axon Server 实例吗？一个应用程序是否应该有两个不同的事件存储，或者我是否将每个事件都转储到一个事件存储中，而不管像聊天系统这样的东西是否发送的事件比其他任何东西都多（事件源是一个聊天系统甚至是一个好主意，考虑到我指定的用户可能想要“重播”聊天日志的用例？）？

3) 单一事件存储作为单一事实来源的整个想法让人感觉很单一。我这样想是不是错了，如果不是，如果我有一个非常大的应用程序，有什么方法可以规避这个问题？

Answer 1

1) 你应该事件源整个应用程序，还是你可以选择哪些事件源而不是事件源？

您可能不应该：如果我将您的应用程序视为子域模型（有界上下文），那么我将能够将这些子域优先考虑为核心、支持和通用。我会在核心（业务的关键差异化因素）和支持子域上使用事件源模式，但我会考虑不在通用子域上使用事件源。通用子域通常是您外包或购买的东西，它们不会为您的业务增加太多价值。

2) Axon Server 是否支持两种不同的事件存储，例如一种用于聊天系统，一种用于其他服务？在这种情况下，我会只运行两个不同的 Axon Server 实例吗？ ...

我已经提到了限界上下文模式。 Axon Server 使您能够使用此模式。 Axon Server 标准版只有一个上下文（称为default）。在 Axon Server Enterprise Edition 中，可以配置多个上下文，然后连接您的应用程序以使用它们（在基于角色的场景中）。每个上下文都物理链接到其自己的事件存储/存储（一个上下文 = 一个存储）。

我不介意将事件保存在单个默认上下文/事件存储中一段时间​​（使用 Axon Server CE）。事件溯源的问题在于您正在将数据与行为分离，并且将来将您的事件存储迁移到多个事件存储应该很容易。我现在将专注于您的应用程序的设计和行为，然后专注于迁移。这是一种进化的方法！

3) 将单一事件存储作为单一事实来源的整个想法让人感觉很单一。我这样想是不是错了，如果我不是，如果我有一个非常大的应用程序，有什么方法可以规避这个问题？

我可能已经在 2) 下回答了这个问题。如果您有松散耦合的应用程序和组件（包括位置透明性），那么您不必担心事件源数据在一个事件存储中。未来它可以发展为更多的事件存储。