Best Way of implementing Application Services? about cleanarchitecture HOT 1 CLOSED

I sometimes find value in using application services. My definition of application services is that they are services specific to the application, and usually that means they're tied closely to the UI. I don't always, or even often, add an application service "layer" because most of the time the UI can interact directly with the domain layer via repositories (to fetch and store entities), entities, and domain services. However, sometimes the UI needs to get data in a particular format that isn't closely mapped to the domain model. In this case, controllers or other UI classes can become bloated with mapping logic and calls to multiple repositories as they try to convert one model to another. This is where application services can be a big help, as they can hide away repositories and the domain layer from the UI layer, and perform any mapping between domain entities and UI-level DTOs or ViewModels, etc.

I do recommend, when possible, that a given class only work with a single abstraction level in terms of its dependencies (i.e. what's being injected via its constructor). It's not a strict rule, but if you can, try to have your services work only with repositories or other services, but not both. Same for controllers. If you're working one level above the repository abstraction level, that's different than if you're working one level above a services abstraction level. When you have mix, it's often a good idea to roll more of the low-level logic up into services so you can eliminate low-level dependencies on repositories, etc.

from cleanarchitecture.