事件源，CQRS与Axon服务器/框架-事件源的整个应用程序是一个好主意？

Question

这个问题与Axon Server/Framework的关系非常松散，因为我是在学习和尝试学习如何构建微服务时专门学习它的。由于在没有实际经验的情况下很难了解所有的架构模式（而且在没有一个大型应用程序来实际测试/构建的情况下，很难从实际经验开始），所以我在这里提出了很多理论（我的问题可能很愚蠢，对不起，我还在学习中）。

我下载了Axon Server，并成功地在三个独立的微服务中构建和运行了包含的giftcard演示。它工作得很好，我在Axon仪表板上看到了事件和所有这些，但我不禁想到如果我真的构建了一个非常大的企业应用程序，“如果”是什么。

考虑一下：

我正在建立一个像Twitch这样的流媒体平台。有一些基本的、显而易见的服务，如带有其配置文件数据的客户服务、订单服务（用于订阅、捐赠）等。

2)Axon Server是否支持两个不同的事件存储，例如一个用于聊天系统，一个用于其他服务？在这种情况下，我是否只运行Axon Server的两个不同实例？应用程序是否应该有两个不同的事件存储，或者我是否将每个事件转储到一个事件存储中，而不管像聊天系统这样的东西发送的事件比其他任何东西都多（如果我指定了查看者可能希望“重播”聊天日志的用例，那么从聊天系统中获取事件是否是一个好主意？）？

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

Answer 1

1）您应该为整个应用程序提供事件源，或者您可以选择哪些应用程序提供事件源而不是事件源？

您可能不应该这样做：如果我将您的应用程序视为子域模型（有界上下文），那么我将能够将这些子域作为核心、支持和泛型来优先考虑。我会在核心（业务的关键区别器）和支持子域上使用eventsourcing模式，但我会考虑不在一般子域上使用eventsourcing模式。通用子域通常是您外包或购买的东西，它们不会为您的业务增加太多价值。

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

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

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