如何解决如何避免在使用CQRS的事件源，事件驱动的体系结构中重复类型定义？
情况
为了更好地理解CQRS，事件源和异步服务通信的概念，我一直在使用Go，MongoDB和RabbitMQ构建一个小型系统。这包括以下内容：
- 命令API：公开API以接受和处理命令，然后将事件写入MongoDB集合（称为“事件”）
- 事件发布者：监视“事件”集合中的更改并将其发布到RabbitMQ
- 事件使用者：从RabbitMQ接收事件，并使用它们来更新经过读取优化的MongoDB集合
- 查询API：公开API以返回物化集合中的数据
（我预想对系统中的每个微服务重复一组相似的应用程序，所有应用程序都通过RabbitMQ异步通信）
问题
我觉得我对这些概念有较高的了解，但是在构建此系统时，我在细节方面遇到了麻烦。我发现我需要：
-
使用BSON作为RabbitMQ负载使事件发布者变得“简单”-感觉MongoDB渗入了设计的其余部分，因为否则我不会选择BSON
-
让事件发布者了解所有事件类型，以便它可以将存储的事件从BSON正确转换为JSON（例如，将日期和UUID重写为字符串）以发布到消息总线上-这似乎很臭，因为各种事件类型都需要在不少于三个单独的位置（命令端，查询端，和事件发布者）进行定义。
问题
-
对于使用CQRS +事件源+消息总线的设计来说，这种类型的问题是正常现象吗？还是我的方法存在根本缺陷？
-
如果这与课程相同，那么在生产环境中使用以上两个选项中的哪一个更好？
我的搜索没有发现有关此问题的任何信息，但是，如果您知道解决该问题的文章或博客文章，那可能就足够了。
解决方法
有事件升级程序的概念。事件升级程序的目的是在发布事件之前（也在聚合水合之前）将来自事件存储的事件作为非类型化的数据结构转换成类型化的数据结构。这些通常用于版本控制中。请记住，事件类型发生变化的可能性越大，系统增长的机会就越大，因此您将无法仅从json / bson反序列化。
一旦输入正确的事件，就可以在json中序列化它们，以将其传递到总线中，然后反序列化到另一端。
必须在至少三个不同的位置（命令端，查询端和事件发布者）定义事件类型
只需在共享库中定义事件类型即可。
它也不相关，但是您确实不需要公交车。在重建投影时，它们会引起更多问题，因为它们无法跟踪上一个读取事件。格雷格·杨（Greg Young）在YouTube上的某个地方谈到了这一点（应该不难发现）。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。