我正在学习微服务。
一方面，文献建议将异步事件发布用于需要在sagas上进行协作或对其他服务发布的事件采取行动的微服务。
另一方面，相同的文献建议不要使用共享库来定义公共事件，因为这会通过该事件库将微服务耦合在一起。
我正在服用疯狂药丸吗？如果这些微服务依赖于这些事件，它们是否还与这些事件相结合？如果是这样，在两个（甚至更多）不同的地方用相同的定义编码完全相同的事件有什么好处？这不是完全违反DRY原则吗？
我开始闻到以缩写BS开头的代码气味。有人会帮我喝剩下的这些吗？还是我只是看到皇帝脱掉衣服一秒钟？
如果是这样，在两个（甚至更多）不同的地方用相同的定义编码完全相同的事件有什么好处？
可能有很多优点-微服务可能使用不同的语言实现。或者使用相同的语言，但是在数据的内存表示形式上有所不同，以适应特定的需求。甚至是内存表示形式中的“相同”，但不同的versions，因为它们的部署时间表不同。
在服务的实现之间分担准备消息库的工作没有天生的错误。但这应该是一种选择，而不是一种要求。尤其是，如果共享实施成为障碍，团队始终可以选择替换库。
两个同意消息将使用UTF-8编码的JSON文档的服务不必使用相同的parser －解析器的选择是实现细节。耦合是与模式（关于消息中字节的语义的约定）有关，而不是与实现有关。
如果将事件视为纯数据对象，则除了通用消息处理和序列化/反序列化代码外，不需要库来处理它们。
微服务的整个要点是具有独立的开发周期，因此，一旦您引入了公共库，就开始制作一个“分布式单体”。该库中的任何更改都将导致所有微服务的重新部署。
没有特定于事件的库，您向其介绍的唯一依赖项是来自另一个微服务的特定事件结构的知识。好吧，这是必要的邪恶。