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 關注
- 142 瀏覽
添加回答
舉報