Hexagonal Architecture for a real-time stock watcher

Question

I'm designing a stock market watcher system.

It accepts registration of patterns from subscribers. Meanwhile it polls latest market info every few seconds, the it supports multiple market, so the polling interval, working hours are depend on different market configuration. It may also dynamically adapt polling rates based on market information or subscriptions.

If the market info matches some pattern, it logs the information, and sends alert to subscribers.

The subscribers, patterns, and logs are undoubtedly domain models.

The market info source, alert fanout are out adapters.

Then where should the polling engine be?

Some approaches came to me:

1. Be a Domain Service: Domain service manage threads to poll market & match patterns.

2. Be an Application Service: Threads are implementation details, so application manage threads for polling, there are also two approaches:

   2a. Application do the most logic, it queries market info, invoke pattern.match(), create logs and sends alerts

   2b. Application just invokes a method like GetInfoAndMatch() in the Domain, Domain handles details like 2a did.

I'm struggling which one is more make sense, what's your opinion?

Answer 1

The polling engine triggers a controller. Just like a user would trigger an update manually. The controller then invokes the use case (or primary port in hexagonal architecture) and passes the result to presenter. The presenter updates the ui models and the views show the new values.

In an rich client application this is non big deal since the controller can directly access the ui models.

In a web application the ui controller is on the client side and the backend controller at the backend side (see this answer for details). Here the backend controller gets either triggered by the "polling engine" or by the client.