Interface for use cases (application services)?

Question

Should Use Cases or Application Services have interfaces and implementations when following a hexagonal architecture with ddd principles? For example, the use case "delete a video", should it have IDeteVideo (interface) and DeletVideoImpl (implementation) implementing that interface?

If the answer is yes, where should the interfaces of the use cases be, in the domain layer or in the application layer? It is obvious that the implementation should always be at the application layer.

I think the use cases is not something that varies frequently, so in my opinion I think that it is not necessary to have an interface, with the implementation it would be enough. But in terms of hexagonal architecture and DDD principles, is something stated regarding this?

Thanks in advance.

Answer 1

I do not see a need for having interfaces for your Application services. As they usually orchestrate specific application use cases there should not be different implementations of the same type of workflow. In addition, they should not have dependencies to infrastructure themselves but rather orchestrate the workflow of actions that need to happen by calling operations on repositories, domain services or aggregates.

What is more important is to make sure that your Application services only access interfaces rather than concrete implementations that are dependent on infrastructure. That means application services should only depend on interfaces to use repositories or components that access other infrastructure (e.g. a service component that makes requests to external systems).

However, if there are interfaces for your application services (or use cases), those interfaces should be defined in the application layer. This is the same rule as for domain interfaces (e.g. repository interfaces) which should reside in the domain layer.

Answer 2

Should Use Cases or Application Services have interfaces and implementations when following a hexagonal architecture with ddd principles?

In short, you usually don't need interfaces on use cases (also named interactors in Clean Architecture) because your primary adapters (client of your hexagone) depend upon the hexagone by nature.

Be aware, you still need it though when crafting a secondary adapter (outside component used by your use case), because your hexagone MUST NOT depend upon any secondary adapters.

BUT, you might still need an interface on your use cases if:

• You want to be able to unit test your primary adapters (although considered as humble object), where you would stub/mock your use cases through its interface.

• You might want to try out several alternatives for use cases in order to experiment, in this case it would act as a meaningful abstraction.

If the answer is yes, where should the interfaces of the use cases be ? In the domain layer or in the application layer?

It should be placed inside the hexagone, at the application layer level, because each of those interfaces defines an application service.