The application I'm developing has:

  • controllers (they are responsible for processing RESTful API calls),
  • services (their methods are being called by controllers, they are responsible for operations with various objects),
  • repositories (their method are being by controllers when they are manipulating various objects)
  • and so on.

Some operations are asynchronous, so a controller runs this operation by calling a separate service and this separate service starts a background job and returns the job ID to the caller. It looks like that:

    public Job deleteHahaha(@PathVariable("id") String id) {
        return jobService.runJob(
                () -> {

Everything's working fine, but I'm not sure that everything's optimal.

Shouldn't I make HahahaService.delete() call JobService.runjob() by itself and return a Job? Won't it be a bad practice when services are coupled and interdependent? At the same time, JobService is a service of another kind than HahahaService, HohohoService and KekekeService, because it's an auxiliary service, so maybe it's OK to use it from another service.

What do you think?



Shouldn't I make HahahaService.delete() call JobService.runjob() by itself and return a Job?

It's important to distinguish between domain services (such as HahahaService, which houses actual business logic) and infrastructure services (such as JobService, which handles scheduling, thread pools etc.). You don't want the domain layer to know about infrastructure because domain logic could be reused across different applications which may require different kinds of infrastructure.

Your example with the controller calling JobService is the right way to do it, because it's the controller's responsibility to know that it is servicing an asynchronous REST endpoint and to schedule a background job.

If you wanted to build a command-line interface in the future, you can reuse HahahaService but the delete operation would likely be synchronous and there would be no need for JobService at all.

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.