我正在通过一些小示例来“玩” Axon Framework，其中查询和命令服务（及其背后的逻辑）在多个Docker容器中作为独立的应用程序运行。
到目前为止，一切正常，我开始发展事件版本控制主题。我还没有实现，但是我喜欢通过JSON模式将事件作为API共享的想法。但是我一直将这种想法与事件主持人的潜在需求联系在一起。
如果我正确地理解每个侦听组件都必须独立上播事件的方法，因此共享上载者可能是一个好主意，那么就不需要不同的实现了，对吗？但是，随后的高潮者似乎已成为API的一部分，还是我错过了一些东西？ 您如何处理这种情况？或者通常，在这种情况下，API定义的最佳实践是什么？
答案 0 :(得分：1)
当访问具有用于不同服务的不同存储库的微服务环境时，我觉得为给定微服务的API提供专用的模块/包/存储库是很常见的。或者，一个有界上下文中共享语言的专用模块。
尤其是当遵循“有界上下文”的概念时，因此上下文中的每个服务都说相同的语言，对我来说，也强调了共享创建的上流者的要求。 很快，是的，我将上载者与相关的API一起分组。
模式语言通常还具有适当的解决方案，以支持例如消息的多个版本。因此，如果您要使用模式语言作为核心API，那么它还将包括（尽管有所不同）upcaster形式。
这是我对情况的2美分；希望这对您有所帮助！