这个问题与 Axon 服务器/框架的关系非常松散，因为我在学习和尝试学习如何构建微服务时专门学习它。由于没有实际动手经验就很难了解所有架构模式(并且如果没有大型应用程序进行实际测试/构建就很难获得动手经验)，我在这里进行了很多理论化(我的问题可能只是很愚蠢，对不起，我还在学习)。
我下载了 Axon Server，并在三个独立的微服务中成功构建并运行了包含的礼品卡演示。它工作得很好，我在 Axon 仪表板上看到了事件和所有这些，但我忍不住想如果我真的构建了一个非常大的企业应用程序的“假设”。
考虑一下:
我正在构建像 Twitch 这样的流媒体平台。有一些基本的、明显的服务，例如带有个人资料数据的客户服务、订单服务(用于订阅、捐赠)等。
但是还有聊天系统等其他服务。假设地，我觉得聊天系统的事件源会非常有益，因为如果观众正在观看 VOD，您将内置时间戳来重播聊天。但是，我也觉得我不应该将聊天系统的事件与处理交易的事件存储混合在一起；这两个是完全独立的系统，只是将来自每个服务的每个事件存储在一个事件存储中感觉......整体？
我仍然不清楚最佳做法是什么。演讲中的所有样本和示例总是显示非常简单的系统，具有典型的客户、订单、项目聚合，并且没有详细说明这个简单的应用程序如何成长为像 Twitch 这样的大型服务。
所以我的问题是，
1) 您应该对整个应用程序进行事件源处理，还是可以选择将哪些应用程序作为事件源而不是？
2) Axon 服务器是否支持两种不同的事件存储，例如一种用于聊天系统，另一种用于其他服务？在这种情况下，我会运行两个不同的 Axon Server 实例吗？一个应用程序是否应该有两个不同的事件存储，或者我是否将每个事件都转储到一个事件存储中，而不管聊天系统之类的东西是否发送比其他任何东西都多得多的事件(事件采购聊天系统甚至是个好主意，鉴于我指定的用例，观众可能想要“重播”聊天记录？)？
3) 单一事件存储作为单一事实来源的整个想法让人感觉是单一的。我这样想是不是错了？如果不是，如果我有一个非常大的应用程序，有什么方法可以避免这种情况？
最佳答案
1) 您应该为整个应用程序提供事件源，还是可以选择哪些事件源而不是事件源？
您可能不应该:如果我将您的应用程序视为子域模型(限界上下文)，那么我将能够将这些子域优先级划分为核心、支持和通用。我会在核心(业务的关键差异化因素)和支持子域上使用事件源模式，但我会考虑不在通用子域上使用事件源。通用子域通常是您外包或购买的东西，它们不会为您的业务增加太多值(value)。
2) Axon 服务器是否支持两种不同的事件存储，例如一种用于聊天系统，另一种用于其他服务？在这种情况下，我会运行两个不同的 Axon Server 实例吗？ ...
我已经提到了限界上下文模式。 Axon 服务器使您能够使用此模式。 Axon 服务器标准版只有一个上下文(称为 default)。在 Axon 服务器企业版中，可以配置多个上下文，然后连接您的应用程序以使用它们(在基于角色的场景中)。每个上下文都物理链接到它自己的事件存储/存储(一个上下文 = 一个存储)。
我不介意将事件保存在单个默认上下文/事件存储中一段时间(使用 Axon Server CE)。 eventsourcing 的事情是你正在将你的数据与行为分离，并且将来应该很容易将你的 eventstore 迁移到多个 eventstores。我现在会专注于您的应用程序的设计和行为，然后再专注于迁移。这是一种进化的方法!
3) 将单个事件存储作为唯一真实来源的整个想法感觉是单一的。我这样想有错吗？如果没有，如果我有一个非常大的应用程序，有什么方法可以避免这种情况？
我可能已经在 2) 下回答了这个问题。如果您有松散耦合的应用程序和组件(包括位置透明性)，您不应该担心您的事件源数据在一个事件存储中太多。它可以在未来发展为更多的事件存储。
关于design-patterns - Event sourcing, CQRS with Axon Server/Framework - Event Sourcing the entire application 是个好主意吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59874140/