在消息代理（ServiceBus）中混合命令和事件

Question

我有 Order 和 OrderProcessor 服务。 订单提交后，必须由 OrderProcessor 处理。处理后，OrderProcessor 应该将响应发送到 Order 服务，并带有 Order 状态，例如失败/成功。我想使用消息代理（Azure ServiceBus）进行异步处理和解耦我的服务。

在命令和事件方面，我看到以下结构：

• ProcessOrder 命令应该在 ServiceBus 中发布。我选择了命令消息，因为我希望处理器进行一些处理。而且只有一个消费者。
• OrderProcessedFailed 或 OrderProcessedSucceeded 事件应在处理完成后在 ServiceBus 中发布。所以我的 Order 服务应该订阅这些事件并正确处理。

在 ServiceBus 中使用队列或主题有两种方法可以实现它。 我想使用一个共享主题，其中将发布 ProcessOrder 消息和 OrderProcessedFailed/OrderProcessedSucceeded 事件。每个服务都有自己的订阅，按事件类型过滤。

我知道，当您采用事件驱动方法时，共享主题结构是简单场景的不错选择。但就我而言，我也有 ProcessOrder 命令。我期待订单将被处理。当我只是提出 OrderCreated 事件（或其他任何事件）并期望对此有任何反应时，情况就不一样了。

在一个共享主题中混合命令和事件实际上是一种好方法，还是完全混合命令和事件？ 将消息驱动的方法与请求和回复队列一起使用会更好吗？并将响应事件替换为 OrderReply 消息（内部带有 Failed/Succeeded 状态）？

其他信息：

我不确定将来会是任何其他命令或/和事件。但如果是这样，最好有易于维护的结构，例如所有服务的共享主题。

我现在知道应该支持不同版本的 OrderProcessors。而且我相信使用带有过滤器的主题和订阅者来处理命令消息版本会更容易。而不仅仅是在应用程序级别过滤消息。

Answer 1

对此不一定有硬性规定，但我个人会采用一种用于命令和一种用于事件的方法——也就是主题和目的之间的 1-1 映射。如果您需要在构建服务时扩展该主题，那么使用具有单个订阅者的主题没有任何问题。

添加不同的 OrderProcessor 可能会很好地使用过滤器，无论是在服务中还是在您的代码中。他们每个人都可以对命令主题有自己的订阅，这样订单服务就不需要知道给定命令最终将使用哪个处理器。

接下来要考虑的是向混合中添加一种完全不同类型的服务——比如从 OrderProcessor 接收命令的东西。如果您最终预计服务的数量会随着复杂的连接而变得相当大，那么拥有该中心命令主题可能是一个不错的选择 - 它允许来自任何组件的命令移动到任何其他组件。

另一方面，如果您的服务类型仍然偏低，那么更狭义地定义目的可能是有意义的——比如将 orderCommands 和 inventoryCommands 分开。如果这是您喜欢的设计，那么在那种情况下使用单个命令主题也不会错。

您还可以使用自动转发将两者结合起来。您的中心命令主题接收所有消息，然后将它们自动转发到 orderCommands 和 inventoryCommands 主题。在大型系统中，这会使您为单个主题管理的订阅数量有所减少。