我们正在将单体架构迁移到更分布式的架构,我们决定使用 AxonFramework。
在 Axon 中,由于消息是一等公民,因此您可以将它们建模为 POJO。
现在我想知道,既然一个事件可以由一个服务分派并监听任何其他事件,我们应该如何处理事件分发。
我的第一个冲动是将它们作为 JAR 文件打包到一个单独的项目中,但这违反了微服务的规则,即它们不应共享实现。
欢迎任何建议。
我们正在将单体架构迁移到更分布式的架构,我们决定使用 AxonFramework。
在 Axon 中,由于消息是一等公民,因此您可以将它们建模为 POJO。
现在我想知道,既然一个事件可以由一个服务分派并监听任何其他事件,我们应该如何处理事件分发。
我的第一个冲动是将它们作为 JAR 文件打包到一个单独的项目中,但这违反了微服务的规则,即它们不应共享实现。
欢迎任何建议。
拥有某种形式的“通用”模块绝对并不少见,尽管我个人会将该“通用”模块单独用于该特定应用程序。
我通常会说您应该将您的命令/事件/查询视为应用程序的 API。因此,与其他项目共享事件结构可能是有益的,但不是实际的 POJO 本身。例如,您可以考虑在此用例中使用 ProtoBuf,在 ProtoBuf 中为您的事件描述了一个模式。
要考虑的另一件事是不要公开您的整个“事件API”。通常,您会遇到一些非常细粒度的事件,这些事件是您环境中的其他(微)服务不感兴趣的。然而,总会有一些“非常重要的事件”,不同的说法是“里程碑事件”,其他人肯定是感兴趣的。在某些场景中,这些里程碑事件不是您领域的直接 POJO,而是几个事件的累积。
因此,拥有一个累积这些并发布另一个事件以通知其他服务的服务并不少见。累积这些细粒度的内部事件,并发布里程碑事件作为对这些事件的响应,通常更适合作为微服务架构中的事件 API。
所以这是给你的一些想法,希望它们能给你一些见解。我想对您的问题给出一个明确的解决方案,但这样的答案总是隐藏在“视情况而定”之后。
你是对的,“官方”规则是不共享模型。所以如果你有分布式的开发团队,我会坚持下去。
但是,当我有解耦但由同一团队或高交互团队开发的组件时,我倾向于不严格遵循......