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 IDeleteVideo (interface) and DeleteVideoImpl (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.
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.