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.

  • DDD is at a ver high levl concepually. Are you sure it really addresses details like threads and progress reporting? – Robert Harvey Oct 12 '12 at 6:47
  • 1
    @RobertHarvey well I have to fit this into an existing DDD application, and I'm trying to figure out where all responsibilities lie. Since I already had a bit of an idea I though I'd ask if that idea would be viable, especially since the implementation details feel "icky". Both the conceptual idea (which layer does what), and the implementation (threads/singleton in memory) are based on assumptions I've made, not on experience. Would you categorize these details differently? – dvdvorle Oct 12 '12 at 7:28
  • IMO this is not related to domain. Operations on items might be, but this is more related to application layer. It is hard to tell if you dont say if it is web or thick client. – Euphoric Oct 12 '12 at 8:18
  • @Euphoric It's a client server application using (self hosted) WCF. – dvdvorle Oct 12 '12 at 9:47

These types of operational concerns are the responsibility of the application layer and as such they are agnostic of DDD. The application layer delegates to the domain layer which can be implemented using DDD. It is atypical for a domain service to spin up worker threads and deal with processing status. Instead, it should be focused on implementing domain logic that does not naturally belong in an aggregate, entity or value object. Management of threads and processing status should be handled by the application layer because it is an operational concern, not a domain concern. There are multiple ways to implement long running processes with progress information. Using threads within an AppDomain is only one way to go. For example, if fault tolerance and distribution is required, it is best to place work items into a durable queue and have a message handler which processes these messages by delegating to the domain layer. Such an implementation is depicted in Request/Acknowledge/Poll With ASP.NET WebAPI and NServiceBus. Regardless of implementation of this application layer responsibility, the domain remains the same.

  • Hi thanks. I'm not looking for something durable or distributed, so something relatively simple as managing my own threads works for me. But I though I read a rule somewhere about that the Application Layer should be stateless. Could you maybe go a bit more into detail of implementing such a thing. Should the Application layer delegate it to something else? – dvdvorle Oct 17 '12 at 8:52
  • You could have the app layer delegate to an infrastructure service which supports long running processes, but the result is the same. Some of this depends on existing code that you have in place. For example, it wouldn't be a good idea to invest a lot of time into creating an abstract task runner in the infrastructure layer if this is the only use case. – eulerfx Oct 18 '12 at 19:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.