Clean Architecture: Is the Input Boundary necessary?

Question

In Clean Architecture boundaries are interfaces, which I model in Python with abstract classes. The input boundary, which is between the controller and the interactor/use case does not need an interface in my opinion, since it just executes the use cases coming from a "higher level". Is this true?

Other boundaries make sense to me having interfaces, because they decouple from the implementation of my presenter/database/api etc. and because they are called from the use case. If I want to interchange the database for example I just use my interface (my abstract class) in order to implement a new database call.

Answer 1

While it's true that the controller to interactor boundary isn't helping you invert a dependency, that isn't why it's there. The reason it's there is this:

• High-level modules should not depend on low-level modules. Both should depend on abstractions.

That's from the Dependency Inversion Principle. All it means is that it's nice to have a stable definition of the mini language that the two volatile concrete modules will communicate through. It means they don't have to know about each other. Just about the mini language. A fully abstract class that isn't bound to any destabilizing implementation details satisfies this just fine.

DIP and Clean Architecture are very closely linked. I mapped the Clean Architecture UML onto DIP here

Answer 2

True. The boundary interface between controller and interactor is not really necessary. If it was not there, the dependency direction would still be correct.

If I were to speculate I would say the boundary interface between controller and interactor is there just for sake of symmetry. As the other boundary interface is necessary to invert the dependency.

It also may be because it makes it possible to create test double for the interactor for the controller, but that is not what this diagram is about.

Also one note : The relationships between the classes do not represent data flow, but compile-time dependencies between the classes, either from usage or from inheritance/implementation. The data and control flows between those classes would look different.