基於事件與版本化事件的集成

Question

我想使用事件來傳達我的服務。 我將發布（內部）我所有的域事件並允許任何其他服務訂閱它們。 但是這種方法將這些服務結合在一起。 我不再被允許更改我的事件。 這甚至比本地耦合更糟糕，因為我不再了解我的消費者了。 這將開發/重構的能力限制為不可接受的 deree。 我正在考慮對我的事件進行版本控制以解決大多數問題。 但是如何訂閱版本化事件呢？ 引入通用接口將所有事件的版本分組，然后將偵聽器中的事件向下轉換為已接受的事件，這聽起來不是一個重要的解決方案。 我還考慮將事件的所有支持版本發布到總線。 根據定義，每個訂閱者將只處理一個版本。 我不希望我的域參與到這件事中，所以我需要構建一種基礎設施偵聽器，將捕獲的事件轉換為其他版本。 我在互聯網上找不到關於該主題的任何內容，如果我沒有完全錯，這會自動讓我思考:)

更新：經過深思熟慮，我不想再發布我的域事件。 我認為將內部服務機制暴露給外部世界是不可取的。 它也可能違反某些域數據訪問限制。 我認為，要走的路是將我的領域事件映射到更多的 corase 集成事件。 但我仍然需要方法來使它們變形 :)

UPDATE2：經過一些協商，一個想法出現了。 假設我們堅持集成事件的概念。 此類事件可以被視為類型和事件 ID。 所以外部監聽器只關注事件類型。 如果事件發生，則將向偵聽器提供事件 ID。 這使偵聽器能夠從給定版本的流/總線/wtf 中獲取真實事件。 $eventsStore->get($eventGuid, $eventType, 'v27')例如（PHP 語法）

Answer 1

我將發布（內部）我所有的域事件並允許任何其他服務訂閱它們。

這是偶數驅動架構中的常見模式。 我假設您在事件代理（例如 Apache Kafka）上發布事件，並且消費者訂閱事件代理上的主題。

我不再被允許更改我的事件。 這甚至比本地耦合更糟糕，因為我不再了解我的消費者了。 這將開發/重構的能力限制到了不可接受的程度。 我正在考慮對我的事件進行版本控制，以解決大多數問題。

不，已發布的合約應該是版本化的，並且不能向它們添加向后兼容的更改。 如果您需要不向后兼容的更改，則必須引入已發布合約的新版本 - 只要有消費者，就保留舊版本。 這與基於 REST 的接口沒有什么不同——你必須履行你的合同。

使用 REST，您可以同時使用/v1/orders和/v2/orders完成此操作。 對於事件驅動架構，您使用兩個主題，例如orders-v1和orders-v2 - 這兩個主題包含遵循架構的數據，例如Avro 。

使用事件驅動的架構，其中服務是解耦的（中間有一個代理），如果您添加一個較小的轉換器，例如使用orders-v2並將事件轉換為舊格式，您實際上可以逐步淘汰舊的生產者並將它們發布到orders-v1 - 所以v1和v2仍然發布。

Building Event-Driven Microservices是一本關於此的好書。