How to manage long running background threads and report progress with DDD
- by Mr Happy
Title says most of it. I have found surprising little information about this. I have a long running operation of which the user wants to see the progress (as in, item x of y processed). I also need to be able to pause and stop the operation. (Stopping doesn't rollback the items already processed.)
The thing is, it's not that each item takes a long time to get processed, it's that that there are usually a lot of items. And what I've read about so far is that it's somewhat of an anti-pattern to put something like a queue in the DB. I currently don't have any messaging system in place, and I've never worked with one either.
Another thing I read somewhere is that progress reporting is something that belongs in the application layer, but it didn't go into the details. So having said all this, what I have in mind is the following.
User request with list of items enters the application layer.
Application layer gets some information from the domain needed to process the items.
Application layer passes the items and the information off to some domain service (should the implementation of this service belong in the infrastructure layer?)
This service spins up a worker thread with callbacks for both progress reporting and pausing/stopping it.
This worker thread will process each item in it's own UoW. This means the domain information from earlier needs to be stored in some DTO.
Since nothing is really persisted, the service should be singleton and thread safe
Whenever a user requests a progress report or wants to pause/stop the operation, the application layer will ask the service.
Would this be a correct solution? Or am I at least on the right track with this? Especially the singleton and thread safe part makes the whole thing feel icky.
