避免在使用 CQRS 的事件源、事件驱动架构中的类型定义重复

今天golang学习网给大家带来了《避免在使用 CQRS 的事件源、事件驱动架构中的类型定义重复》，其中涉及到的知识点包括等等，无论你是小白还是老手，都适合看一看哦~有好的建议也欢迎大家在评论留言，若是看完有所收获，也希望大家能多多点赞支持呀！一起加油学习~

情况

为了更好地理解 CQRS、事件源和异步服务通信的概念，我一直在使用 Go、MongoDB 和 RabbitMQ 构建一个小型系统。这包括以下内容：

• 命令 API：公开 API 来接受和处理命令，然后将事件写入 MongoDB 集合（称为“事件”）
• 事件发布者：监视“事件”集合的更改并将其发布到 RabbitMQ
• 事件使用者：从 RabbitMQ 接收事件并使用它们来更新读取优化的 MongoDB 集合
• 查询 API：公开 API 以从物化集合返回数据

（我设想为系统中的每个微服务重复一组类似的应用程序，所有应用程序都通过 RabbitMQ 异步通信）

问题

我觉得我对这些概念有了很好的掌握，但是在构建这个系统的过程中我在细节上遇到了一些麻烦。我发现我需要：

1. 使用 BSON 作为 RabbitMQ 有效负载，让事件发布者的事情变得“简单” - 这感觉就像 MongoDB 正在渗透到设计的其余部分，因为否则我不会选择 BSON

2. 使事件发布者了解所有事件类型，以便它可以正确地将存储的事件从 BSON 转换为 JSON（例如，将日期和 UUID 重写为字符串）以发布到消息总线 - 这似乎有味道，因为各种事件类型需要在不少于三个个不同的地方定义（命令端、查询端、和事件发布者）。

问题

1. 这种类型的问题对于使用 CQRS + 事件源 + 消息总线的设计来说是正常现象，还是我的方法存在根本缺陷？

2. 如果这是课程的标准，那么上述两个选项中哪一个更适合在生产环境中使用？

我的搜索没有发现任何有关此问题的信息，但如果您知道解决该问题的文章或博客文章，那么可能就足够了。

解决方案

这里有事件升级器的概念。事件升级器的目的是在发布事件之前（也在聚合水合之前）将来自事件存储的事件作为非类型化数据结构转换为类型化数据结构。这些经常用于版本控制。请记住，系统的增长越大，您的事件类型发生变化的机会就越大，因此您将无法仅从 json/bson 反序列化。

正确输入事件后，将它们序列化为 json，将它们传递到总线中，并在另一端反序列化它们。

事件类型需要在不少于三个单独的位置定义（命令端、查询端和事件发布者）

只需在共享库中定义您的事件类型即可。

另外，这不相关，但你真的不需要公共汽车。当涉及到重建投影时，它们会导致更多问题，因为它们不跟踪上次读取事件。 Greg Young 在 YouTube 上的某个地方谈论过它（应该不难找到）。

本篇关于《避免在使用 CQRS 的事件源、事件驱动架构中的类型定义重复》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！