六边形架构中异步响应处理应归属驱动层还是被驱动层？

我们团队刚接触六边形架构，正在探讨各类场景的最佳实现方案。线上多数示例展示了典型流程：command/query -> use case -> db/msg/api，但**异步响应处理（如响应主题消费、HTTP回调接收、轮询远程端点）**引发了大量争论。

我们的前提假设：

• Driven端口仅由应用层/用例调用
• 用例仅由Driving层调用

两种方案的核心分歧 #

1. 驱动侧响应处理 #

这种方案将异步响应的接收逻辑（比如用@KafkaListener、@RestController、@SqsListener实现的消息消费/HTTP回调接口）放在驱动层，与框架提供的消息、API抽象高度契合。处理器直接调用应用层的用例完成业务逻辑。

2. 被驱动侧响应处理 #

另一种观点基于Alistair Cockburn对secondary actors/driven层的定义——处理与外部主体的对话，认为异步响应属于同一对话的后续环节，因此将响应处理放在被驱动层。这种方式的优势是便于后续切换为同步模式，但会增加复杂度（比如需要应用层编排轮询响应的逻辑）。

业界主流解读与实践建议 #

驱动侧方案：更贴合现代框架与异步场景 #

大部分业界实践更倾向于将异步响应处理放在驱动层，原因如下：

• 框架适配性：现代框架的消息监听、HTTP回调注解本身就是驱动层的典型实现，直接复用这些抽象可以减少自定义适配代码，降低维护成本。
• 职责清晰：驱动层的核心职责是接收外部触发的请求（不管是主动的command/query，还是被动的异步响应），将这类逻辑统一放在驱动层，符合"单一职责"原则，也让架构边界更清晰。
• 复杂度可控：直接调用用例的方式避免了应用层额外编排轮询等逻辑，减少了不必要的复杂度，更适合异步场景的快速实现。

被驱动侧方案：适合需要多模式兼容的场景 #

被驱动侧方案并非没有价值，当你的业务场景需要在同步/异步模式之间灵活切换时，这种设计更有意义：

• 它把与外部系统的完整对话（请求发送+响应接收）封装在被驱动层内部，应用层只需要调用统一的端口，无需关心底层是同步还是异步实现。
• 但代价是需要额外的编排逻辑（比如应用层触发轮询、或者被驱动层内部维护对话状态），增加了架构的复杂度，因此只适合有明确多模式兼容需求的场景。

总结判断 #

• 如果你的场景以异步响应为主，且不需要切换为同步模式，优先选择驱动侧方案，适配性更好、复杂度更低。
• 如果你的业务需要同步/异步模式灵活切换，或者希望将与外部系统的完整对话封装为独立单元，可以考虑被驱动侧方案，但要做好复杂度管控。

内容的提问来源于stack exchange，提问作者miklesw