事件源,带有Axon Server /框架的CQRS-为整个应用程序提供源代码是一个好主意吗?

这个问题与Axon Server / Framework非常松散相关,因为我在学习和尝试着学习如何构建微服务时专门学习了它。由于没有实际经验就很难了解所有架构模式(并且如果没有大型应用程序来实际测试/构建就很难获得经验),因此我在这里做了很多理论上的介绍(我的问题可能只是很愚蠢,对不起,我还在学习)。

我下载了Axon Server,并在三个独立的微服务中成功构建并运行了所包含的giftcard演示。它工作得很好,我在Axon仪表板上看到了事件以及所有事件,但是我不禁要想一想,如果我真的构建了一个大型企业应用程序,该怎么办。

考虑这个:

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

但是还有其他服务,例如聊天系统。假设地,我认为事件来源的聊天系统将是非常有益的,因为如果观众正在观看VOD,则您将内置用于重播聊天的时间戳。但是,我也觉得我不应该将聊天系统的事件与处理事务的事件存储区混合在一起。这两个系统是完全独立的系统,只是将每个服务中的每个事件存储在一个事件存储中就感觉...整体式的?

我仍不清楚最佳实践是什么。演讲中的所有示例和示例始终显示出非常简单的系统,其中包含典型的“客户”,“订单”,“项目”聚合,并且没有详细说明此简单应用程序将如何发展为Twitch之类的大型服务。

我的问题是,

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

2)Axon Server是否支持两个不同的事件存储,例如一个用于聊天系统,另一个用于其他服务?在这种情况下,我将只运行两个不同的Axon Server实例吗?如果应用程序有两个不同的事件存储区,或者我将每个事件都转储到一个事件存储区中,无论聊天系统是否发送的事件比其他事件多(无论事件来源是聊天系统,还是个好主意,给定我指定了观众可能想“重播”聊天日志的用例?)?

3)将单个事件存储作为真理的唯一来源的整个想法让人感到一头雾水。我是不是想错了,如果不是,那么,如果我有一个非常大的应用程序,有什么方法可以绕开它?

zzp0706034135 回答:事件源,带有Axon Server /框架的CQRS-为整个应用程序提供源代码是一个好主意吗?

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

您可能不应该:如果我将您的应用程序视为子域模型(有界上下文),则可以将这些子域划分为Core,Supporting和Generic。我会在Core(业务的主要区别因素)上使用事件外包模式,也许还会在支持子域上使用,但是我会考虑不在通用子域上使用事件外包。通用子域通常是您外包或购买的东西,它们不会为您的业务增加太多价值。

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

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

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

3)将单个事件存储作为真理的唯一来源的整个想法让人感到一头雾水。我的想法是否正确?如果不是,那么,如果我有一个非常大的应用程序,该如何规避?

我可能已经在2)下回答了这个问题。如果您具有松散耦合的应用程序和组件(包括位置透明性),则不必担心事件源数据在一个事件存储库中的存储量会很大。将来可以扩展到更多的事件存储。

本文链接:https://www.f2er.com/2726825.html

大家都在问