Hi Abelardo,

your controller would not implement an interface, instead it would call an interface (a port) to act on your application. That interface is part of your application, and typically expresses a use case or a "service" that your application is offering. For example your UserController may handle an HTTP POST on /users to register a user... the controller would get the raw data (e.g. the user details) from the body of the HTTP request, convert it in a sort of input data class (maybe a Command class) and call a RegisterUserUseCase, which may be an interface, implemented somewhere in the application... That said, I typically don't use a separated interface for the incoming ports: they are implemented as concrete classes.

The need to have an interface here is not so strong though, because the direction of the dependencies already goes inward, and that's good because your app (your domain) won't depend on the infrastructure.

The most important place where you should have interfaces is when you, from inside your domain, are reaching and calling external systems or dependencies (eg. a database to save the user data): there you have to invert the dependencies, so you'll need to call a port (an "outgoing" port, e.g. UserRepository) that will be implemented in the infrastructure part (e.g. MySqlUserRepository).