3 回答

TA贡献2065条经验 获得超14个赞
如果它能帮助你,我的设计将如下:
司机演员:
人类用户:使用驱动程序端口与应用交互:“用于添加设备”
设备(IP 摄像头):使用另一个驱动程序端口向应用发送警报事件:“用于接收警报事件”
驱动演员:
设备(IP摄像头):该应用程序使用“用于检查设备”的驱动端口与设备进行交互,以便根据设备的时间表每天启动和停止它。
警告收件人:当收到警报事件时,应用会向他们发送电子邮件,并且不会忽略该事件。
警报事件存储:用于保留应用收到的警报事件。
该应用程序(“警报监视器”)执行以下业务逻辑:
维护它必须监视的设备集合(“用于添加设备”)。
它有一个“工作器”(调度程序),定期检查设备状态并根据设备的调度启动/停止它们。
它处理从设备收到的警报事件。收到警报事件时,应用会发送电子邮件或忽略它。并将事件存储在存储库中。
所以对我来说:
调度程序是业务逻辑的一部分。
接收器是设备的适配器。它与http的东西有关。
这是图片:

TA贡献1886条经验 获得超2个赞
“调度程序负责定期检查接收方是否应根据其调度启动”
最终,对于应用程序来说,人类是按“自动启动接收者”按钮还是由计划过程完成并不重要。因此,这是一个基础结构问题,计划程序是一个驱动程序适配器。您可能有一个服务命令,该命令将由调度程序定期调用。ReceiverService.autoStartReceivers
现在,我会说这取决于实现。如果不知道特定于基础结构/供应商的详细信息,而只知道协调,则它可能属于应用程序/服务层。Receiver
Receiver
例如,也许接收方使用抽象(HTTP,WebSockets等)并使用(特定于供应商的)来调整事件,然后将它们中继到实际上只是在进行编排。& 将是适配器。但是,如果知道特定的基础结构详细信息,那么它就变成了适配器。EventSource
EventDecoder
EventProcessor
EventSource
EventDecoder
Receiver
最终,以上所有内容都是对事件处理的核心域的支持逻辑。核心域逻辑不会真正关心事件是如何捕获的,也可能不关心结果操作是如何进行的。因此,您的核心域在最简单的形式中可能是纯函数。actions = process(event)

TA贡献1789条经验 获得超8个赞
一个。两者在同一封装中,并放置在适配器层
b.适配器层中的接收方和服务层中的调度程序
c. 服务层中的调度程序和接收方?
接收方和调度程序都是适配器。我不认为它们必须放在同一个包中,但你可以这样做。对我来说,最好的答案也是如此,因为...a
接收器将您的应用程序与外部设备-ip卡马拉连接。因此,接收器是端口的适配器。EventService
调度程序通过端口间接管理接收方的生命周期。它启用或禁用ip卡马拉,这会导致接收器的连接和断开。DeviceService
从应用程序核心的角度来看,调度程序只是另一个适配器,它告诉端口启用或禁用某些ip camara。这也可以由单击 UI 中的按钮的用户完成。调度程序只是对用户的技术帮助,它根据计划执行用户想要的任务。因此,调度程序也是一个适配器。DeviceService
- 3 回答
- 0 关注
- 152 浏览
添加回答
举报