周期性后台任务适合六边形架构中的什么位置？

Question

我正在 golang 中开发一个程序，该程序是基于六角形架构构建的。我想我的脑子主要围绕着这个想法，但有些东西我就是想不通。

该程序的功能是监控多个IP摄像机的警报事件，接收器可以通过HTTP2.0 PUSH REQUEST接收警报事件的实时流。（以防万一这不是技术术语，我的服务根据 GET 请求建立 TCP/HTTP 连接并保持打开状态，当摄像机触发警报事件时，摄像机将其推送回服务）

架构层次

适配器

• HTTP处理程序
• 内存中 JSON 存储

港口

• 设备服务接口
• 事件服务接口
• 设备库接口
• 事件存储库接口

服务

• 设备服务
• 事件服务

领域

• 设备域
• 事件域

用户通过 API 将设备添加到系统，请求包括所需的监控计划（接收器每天应启动和停止的时间）和 url。

调度程序负责定期检查接收器是否应根据其时间表启动。如果它要为某个设备运行，它将启动该设备的接收器。

接收器建立与 IP 摄像机的连接，并循环处理警报事件流并将其传递给EventService。

EventService 接收事件，并负责根据域逻辑处理该事件，并决定发送电子邮件或忽略它。它还将所有事件保存到 eventrepo。

我不确定代码的两部分是调度程序和接收器。他们也应该如此；A。两者在同一个包中并放置在Adapters 层 b．适配器层的接收器和服务层的调度器 c．服务层的调度程序和接收器？

我只是很困惑，因为接收器不是由用户直接启动的，而是由不断检查条件的运行循环启动的。但我也可能为不同品牌的相机配备不同的接收器。这是一个实现细节，这意味着接收者应该位于适配器层。这让我认为选项 b 是最好的。

我可能想得太多了，但请让我知道你们认为最好的选择是什么，或者建议一个更好的选择。

Answer 1

“调度程序负责定期检查接收器是否应根据其时间表启动”

最终，对于应用程序来说，无论是人类定期按下“autoStartReceivers”按钮还是通过调度进程完成，这并不重要。因此，这是一个基础设施问题，调度程序是一个驱动程序适配器。您可能有一个ReceiverService.autoStartReceivers由调度程序定期调用的服务命令。

现在Receiver我想说这取决于实施。如果Receiver不了解基础设施/供应商特定的细节，但只进行协调，那么它可能属于应用程序/服务层。

例如，接收器可能使用抽象EventSource（HTTP、WebSockets 等）并使用EventDecoder（特定于供应商的）来适应事件，然后将它们中继到然后EventProcessor它实际上只是在进行编排。&是适配器EventSource。EventDecoder然而，如果Receiver了解特定的基础设施细节，那么它就成为一个适配器。

最终，以上所有内容都是事件处理核心领域的支持逻辑。核心域逻辑不会真正关心事件是如何捕获的，也可能不会关心结果操作是如何进行的。因此，最简单形式的核心域可能是actions = process(event)纯函数。