情況為了更好地理解 CQRS、事件溯源和異步服務通信的概念，我一直在使用 Go、MongoDB 和 RabbitMQ 構建一個小型系統。這包括以下內容：命令 API：公開一個 API 以接受和處理命令，然后將事件寫入 MongoDB 集合（稱為“事件”）事件發布者：監視“事件”集合的更改并將其發布到 RabbitMQ事件消費者：從 RabbitMQ 接收事件并使用它們來更新讀取優化的 MongoDB 集合查詢 API：公開一個 API 以從物化集合返回數據（我設想為系統中的每個微服務重復一組類似的應用程序，所有這些應用程序都通過 RabbitMQ 異步通信）問題我覺得我在高層次上對這些概念有了不錯的掌握，但是在構建這個系統時，我在細節上遇到了一些麻煩。我發現我需要：使用 BSON 作為 RabbitMQ 有效負載，使事件發布者的事情變得“簡單”——這感覺就像 MongoDB 正在泄漏到設計的其余部分，因為否則我不會選擇 BSON讓事件發布者知道所有事件類型，以便它可以正確地將存儲的事件從 BSON 轉換為 JSON（例如，將日期和 UUID 重寫為字符串）以發布到消息總線 - 這似乎很臭，因為各種事件類型都需要在不少于三個不同的地方（命令端、查詢端和事件發布者）定義。問題對于使用 CQRS + 事件溯源 + 消息總線的設計來說，這種類型的問題是正常發生的，還是我的方法存在根本缺陷？如果這是課程的標準，那么以上兩個選項中的哪一個更適合在生產環境中使用？我的搜索沒有發現任何關于這個問題的信息，但如果你知道一篇文章或博客文章解決了這個問題，那可能就足夠了。