是否有一些准则来标识DDD中有界上下文的RabbitMQ队列

Question

我准备围绕RabbitMQ队列制作一个域驱动设计队列，对此我是完全陌生的。我想知道是否有一些准则可以在考虑到受限上下文的情况下识别不同的队列。

诸如在每个受限上下文中一个队列，或在受限上下文中每种资源类型一个队列的东西。

并且由于队列通常会跨越不同的有界上下文，因此事情变得更加复杂。

有什么建议吗？

Answer 1

我倾向于使用2个主要的“关注点”（层）。

对于任何大小合适的软件系统，我将在每个有界上下文中使用一个队列，该队列仅与来自相关BC的命令有关。处理消息的端点将按照System.BoundedContextA.Server的方式命名，并且该端点将仅处理来自BoundedContextA的命令。

对于BoundedContextA“拥有”的任何业务流程，我都会有另一个与业务流程有关的端点/队列处理事件。该端点不仅处理与BoundedContextA相关的消息，而且还处理可能与业务流程有关的来自其他BC的消息。该端点将按照System.BoundedContextA.Orchestration的行命名。

端点可以水平缩放，使用RabbitMQ时特别容易。

Answer 2

域驱动设计本身不规定此类模式。但它确实规定您围绕您的域进行设计，而不是围绕基础架构详细信息（例如代理，队列等）进行设计。

说；并假设您正在执行OOP，将您的域对象视为一等公民将可能意味着您将使域与基础架构完全脱钩，从而邀请擅长此操作的常见模式，例如hexagonal architecture。

即使如此，DDD也不规定任何特定的集成方法。您询问队列的事实表明您正在考虑 异步集成 。这样做没有错，但是总能得到deffer architecture decisions的回报。特别是如果您“即将”通过DDD发现此域。尝试start simple，松散耦合，但是monolith-first，您可能会发现根本不需要队列。

考虑到以上所有内容，在与RabbitMQ进行异步集成的情况下，通常使用pub-sub模式。所有相关事件都发布给一个交易所，而无需考虑特定的消费者。消费者根据需要设置自己的队列和绑定，因此没有一个有效的公式：

• 每个消费者每个事件类型一个队列
• 每个使用者一个队列，具有针对事件类型或主题模式的多个绑定
• 使用者实例之间共享的队列以进行负载平衡
• ...以及这些的许多组合。

Answer 3

每种类型的使用者都需要一个队列。

考虑一种消费者C1类型，它处理E1和E2类型的事件。需要队列Q1，所有类型为E1和E2的事件都被路由到该队列中。如果另一类使用者C2处理E3和E4类型的事件，则需要一个队列Q2，所有E3和E4类型的事件都将路由到该队列中。