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.

Answer 3

When implementing DDD using hex arch, the interfaces of the application services are the driver ports (the use case boundary, the left edges of the hexagon).

The inside of the hexagon is splitted into two parts: the application services implementation, and the domain.

Answer 4

I was thinking about the same. Since you are having only one use case per application service you don't need to have an interface. This comes from my practice with different teams in which we didn't have an interface for just one implementation. Also, I agree that application service interfaces (if you have them) should be defined in the application layer. But I have seen them also in the infrastructure layer.