Hexagonal Architecture中周期性后台任务所属层级及实践咨询

你倾向的方案b（receiver归属Adaptors层，scheduler归属Service层）是完全符合六边形架构设计原则的合理选择，是当前场景下的最优解。

层级划分依据 #

receiver归Adaptors层的原因 #

• Adaptors层的核心职责是封装所有与外部系统交互的实现细节，屏蔽外部依赖的差异，核心业务层不需要感知具体的外部对接逻辑。receiver直接对接不同品牌的IP摄像机，不同厂商的HTTP2.0推送逻辑、鉴权规则、事件报文格式都可能存在差异，属于典型的可替换的外部对接实现，放在Adaptors层完全符合定位。
• 建议配套在Ports层定义EventReceiver通用接口，核心服务层只依赖该接口调用receiver的启停、事件接收能力，后续新增摄像机品牌只需要新增Adaptors层的receiver实现即可，无需修改核心逻辑。

scheduler归Services层的原因 #

• Services层的核心职责是实现业务规则、编排业务流程，不依赖任何外部系统的具体实现。scheduler的核心逻辑是根据用户配置的监控计划判断设备接收任务的启停时机，属于核心业务规则的一部分，和外部对接细节无关，放在Services层是合理的。
• scheduler只需要依赖Ports层的抽象接口（比如设备查询接口、EventReceiver接口）即可实现调度逻辑，不需要耦合任何具体的receiver实现，完全符合依赖倒置原则。

可选优化建议 #

如果要进一步提升架构的扩展性，可以把scheduler的定时触发逻辑（比如你使用的Go cron库的启动、定时回调入口）单独放在Adaptors层作为驱动适配器，核心的调度判断、任务启停逻辑保留在Services层，后续如果要新增人工触发调度、外部API触发调度的需求，只需要新增对应驱动适配器即可，无需修改核心调度逻辑。

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