Is a good practice to create Interfaces for use case objects?

Question

Are use case classes (application services on DDD or a.k.a. Facades) stable? Should controllers and listeners be coupled with interfaces at all?

Answer 1

The use-case in a clean architecture is as stable as the other inner circles and more stable than the outer circles such as presenters or UIs:

We do not expect changes in this layer to affect the entities. We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks.
- Uncle Bob

But being stable does not mean that they won’t evolve. Typically at the begin of the project you may have a simplified understanding of the requirements that will get refined as you make progress. For example some use-case could appear to have several variants. So you might need more details for use case implementation than what the outer layers need to know.

This brings us to the dependency inversion principle:

Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

When you design the outer rings, you will depend on the inner ring (that’s the dependency rule of the clean architecture). Therefore you need interfaces to abstract the use-cases, so that the outer rings still depend on abstractions.

Furthermore you may also want to evolve in the outer ring and design some abstractions of the presenters, controllers or whatever before implementing them. So each ring needs the interface for decoupling it from the other rings, and to leave freedom in its own implementation.