DDD实践中微服务对接第三方外部WebSocket的架构设计问题

分层职责边界定义 #

严格按照DDD分层规则拆分WS相关逻辑，避免技术实现侵入业务域：

• 基础设施层：负责WS全生命周期管理，包含连接实例化、心跳保活、异常重连、消息编解码、序列化/反序列化逻辑，同时封装对外发送WS消息的底层能力。该模块本质是DDD中的防腐层，完全屏蔽第三方WS的实现细节，仅对外暴露两个通用能力接口：① 第三方消息推送的回调注册接口 ② 向第三方发送消息的通用接口，所有入参出参均使用业务统一DTO格式，与第三方WS报文格式完全解耦。

该层禁止实现任何业务逻辑，仅处理纯通信层面的技术问题。

• 应用层：收敛所有WS双向交互的业务流程编排：
  • 接收链路：基础设施层收到WS推送后，通过注册的回调将DTO传递给对应应用服务，由应用服务完成参数校验、第三方消息鉴权，随后调用领域服务完成聚合状态更新、核心业务逻辑执行，按需触发仓储持久化操作。
  • 发送链路：领域逻辑执行完成后如果需要向第三方WS回传消息，由应用服务直接调用基础设施层的WS发送接口传入业务DTO即可，无需感知底层连接状态。
  • 低延迟优化：如果业务对延迟要求极高，可调整执行顺序，先更新内存中的聚合实例返回结果，再异步执行持久化操作，通过补偿机制保证最终一致性即可。
• 领域层：完全不感知WS的存在，所有聚合、领域服务的方法仅接收领域对象或基础数据类型入参，仅处理核心业务逻辑，数据来源是HTTP请求、WS推送还是MQ消息对领域层完全透明，符合DDD的领域无关性要求。

高可用兜底方案 #

• 在基础设施层实现轻量消息缓冲队列，峰值场景下暂存未处理的WS推送消息，避免消息丢失
• WS断连重连后，由应用层触发一次全量状态同步逻辑，补全断连期间遗漏的推送数据，保证聚合状态的最终正确性

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