在我看来，他们只是没有绘制从事件处理器返回的事件，可能是因为它们可能不是特定的事件（例如某种回调），或者因为它们可能不是正常事件（也许只是返回的事件到调解员，并且对任何其他订阅者不可见），具体取决于您用作调解员的内容。这部分似乎表明这样的事情：
事件中介可以以多种方式实现。了解每个实施选项，以确保您为事件调解器选择的解决方案符合您的需求。
事件中介的最简单和最常见的实现是通过开源集成中心，例如 Spring Integration、Apache Camel 或 Mule ESB。这些开源集成中心中的事件流通常通过 Java 代码或 DSL（领域特定语言）实现。对于更复杂的中介和编排，您可以将 BPEL（业务流程执行语言）与 BPEL 引擎（如开源 Apache ODE）结合使用。BPEL 是一种标准的类似 XML 的语言，它描述了处理初始事件所需的数据和步骤。对于需要更复杂的编排（包括涉及人工交互的步骤）的非常大的应用程序，您可以使用诸如 jBPM 之类的业务流程管理器 (BPM) 来实现事件中介。
了解您的需求并将它们与正确的事件中介器实现相匹配对于使用此拓扑的任何事件驱动架构的成功至关重要。使用开源集成中心进行非常复杂的业务流程管理编排是失败的秘诀，就像实施 BPM 解决方案来执行简单的路由逻辑一样。
他们提到 Spring 作为一种可能的实现——我从未使用过它，但查看文档（此处）我看到了回复通道的概念：
...当服务方法返回非空值时，端点将尝试将回复消息发送到适当的回复通道。
目标是发送一条或多条消息以异步处理，然后在结果返回时发送其他消息。我认为这些结果如何返回（函数回调、“响应”事件、Web API 调用等）在模式级别并不重要——这取决于您的特定基础设施。
对我来说，这听起来有点像 Saga 模式（链接）。在那里，Saga（或中介者）知道完成某些任务所需的步骤，并维护有关该任务进度的某些状态。
它触发要处理的命令并监听响应。当响应（事件）进入时，它会更新其状态，然后使用其状态来确定接下来需要触发哪些命令。
这种情况一直持续到 A) 过程完成，或 B) 过程中的一个步骤失败（在这种情况下，它可能会反转方向并开始触发补偿命令以“撤消”先前的操作）。
使用您引用的帖子中的下图，传奇/调解人的“想法”可能与......
- 重定位事件，因此触发更改地址命令并等待。
- 收到 AddressChanged 事件。现在我已经更改了地址，但我没有重新计算报价或更新索赔，所以我将把它们发送出去（它们不冲突，所以把它们都发送）然后等待。
- 收到 ClaimsUpdated 事件。在继续前进之前仍然需要重新计算，所以请继续等待。
- 收到 QuoteRecalced 事件。现在我已经更新了地址、重新计算了报价并更新了索赔，我可以发送 Adjust Claims 命令，然后等待。
... 等等。
您可能想要添加持久性（这样它可以在崩溃的情况下从中断的地方继续）、幂等事件处理器（因此重放事件不会导致问题）和/或超时（不会永远卡住等待如果响应事件丢失/丢失）。
