go - 六边形架构中的哪些地方适合周期性的后台任务?

标签 go architecture domain-driven-design clean-architecture hexagonal-architecture

我正在用 golang 编写一个程序,我正在构建基于六边形架构的程序。我想我的头脑主要围绕这个想法,但有些事情我就是想不通。
该程序的功能是监控多个 IP 摄像机的报警事件,接收器可以通过 HTTP2.0 PUSH REQUEST 接收报警事件的实时流。 (以防万一这不是技术术语,我的服务从 GET 请求建立 TCP/HTTP 连接并保持打开状态,当摄像机触发警报事件时,摄像机将其推回服务)
建筑层次
适配器

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

  • 端口
  • 设备服务接口(interface)
  • 事件服务接口(interface)
  • DeviceRepo 接口(interface)
  • EventRepo 接口(interface)

  • 服务
  • 设备服务
  • 事件服务

  • 域名
  • 设备域
  • 事件域

  • 用户通过 API 向系统添加设备,请求包括所需的监控时间表(接收器每天应启动和停止的时间)和 url。
    调度器负责定期检查接收器是否打算根据其调度启动。如果它打算为设备运行,它会为该设备启动一个接收器。
    接收器建立与 IP 摄像机的连接并循环处理警报事件并将它们传递给 EventService。
    EventService 接收事件,并负责处理事件,基于域逻辑,并决定发送电子邮件或忽略它。它还将所有事件保存到 eventrepo。
    代码的两部分我不确定它们在哪里是调度程序和接收器。他们也应该如此;
    一种。都在同一个包中并放置在 Adapters 层
    中的接收器适配器层 和Service层的调度器
    C。服务层中的调度器和接收器?
    我只是很困惑,因为接收器不是由用户直接启动的,而是由一个不断检查条件的运行循环启动的。但对于不同品牌的相机,我也可能有不同的接收器。这是一个实现细节,这意味着接收器应该在适配器层。这让我认为选项 b 是最好的。
    我可能想多了,但让我知道你们都认为最好的选择是什么,或者建议一个更好的选择。

    最佳答案

    如果它可以帮助你,我的设计如下:
    司机 Actor :

  • 人类用户:使用驱动程序端口与应用程序交互:“用于添加设备”
  • 设备(IP 摄像头):使用另一个驱动程序端口向应用程序发送警报事件:“用于接收警报事件”

  • 驱动的 Actor :
  • 设备(IP 摄像头):应用程序使用驱动端口“检查设备”与设备交互,以便根据设备的时间表每天启动和停止它。
  • 警告收件人:当收到警报事件时,应用程序会向他们发送电子邮件,并且不会被忽略。
  • 警报事件存储:用于持久化应用程序接收的警报事件。

  • 该应用程序(“警报监视器”)执行以下业务逻辑:
  • 维护它必须监视的设备集合(“用于添加设备”)。
  • 它有一个“ worker ”(调度程序),它定期检查设备状态并根据设备的调度启动/停止它们。
  • 它处理从设备接收到的警报事件。当收到警报事件时,应用程序会发送电子邮件或忽略它。并将事件存储在存储库中。

  • 所以对我来说:
  • 调度程序是业务逻辑的一部分。
  • 接收器是设备的适配器。它处理http的东西。

  • 这是图片:
    enter image description here

    关于go - 六边形架构中的哪些地方适合周期性的后台任务?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/68789016/

    相关文章:

    sorting - golang排序 slice 升序或降序

    string - 判断一个字符是字母还是数字

    android - Web 服务和 Android 的架构

    c# - 如何组织架构WPF项目?

    c# - 如何构建F#类型的业务规则?

    git - 在公司防火墙后面如何让 go get 为 golang.org 工作

    http - 使用 `http.NewRequest(...)` 发出 URL 编码的 POST 请求

    .net - Azure 响应队列管理

    architecture - 多层架构 - 责任问题

    domain-driven-design - DDD 用两个聚合中的不变量修改每个事务的一个聚合