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