8

Can you explain me what are the benefits of such abstraction as Input Ports in Clean Architecture? Why not use Interactors / Use Cases directly? I understand the role of Output Ports - this way use cases don't have to know about presenters and other adapters. But can't wrap my head around this one. In addition, is there any relation between repository interface and ports? Can repository interfaces be considered Input or Output ports? Thank you!

rasuru
  • 273
  • 1
  • 10

2 Answers2

3

This serves to implement the Open-Closed Principle.

A software artifact should be open for extension but closed for modification.

Read more about this in chapter 8 of Uncle Bob's Clean Architecture book. Here he writes in the subchapter Information Hiding:

Transitive dependencies are a violation of the general principle that software entities should not depend on things they don’t directly use. We’ll encounter that principle again when we talk about the Interface Segregation Principle and the Common Reuse Principle.

and further:

So, even though our first priority is to protect the Interactor from changes to the Controller, we also want to protect the Controller from changes to the Interactor by hiding the internals of the Interactor.

hschaeufler
  • 116
  • 6
1

The Input and Output ports are nothing more than an application of the Dependency Inversion Principle of SOLID in clean Architecture. In most programming languages, they are interfaces (or abstract interfaces). If you look at the original diagram below.

You can see that Controller calls a method on Input Port interface, UseCase implements it, and then UseCase sends a response to the Output Port interface, which Presenter implements. In this case, all implementations of a part of the system can be replaced, since they depend only on the interfaces. enter image description here

alex_noname
  • 26,459
  • 5
  • 69
  • 86
  • Why Controller calls Input Port instead of Interactor directly? It wouldn't break the dependency rule (Use Cases still wouldn't know about Adapters). On the other hand Output Ports are clear as sky should be there, so that Use Cases don't call Presenters directly. But why call Input Ports? Does is suppose that at some point in time I would want to swap Interactor implementation? If yes, amount of changes I would have to make would be the same without this abstraction, because each Use Case is mentioned only once by Controllers. So what's the use? – rasuru Dec 06 '20 at 19:40
  • 1
    A port interface is a contract. As you rightly noted, the interactor can be completely changed, but the contract must be respected and these changes will not affect other parts of the system. It's not about the number of changes, but the compliance with the contract. – alex_noname Dec 07 '20 at 07:19
  • Okay, thinking about it, I think it would be nice to have some set of Input Ports so that I could say that actually my Interactor implements a different Input Port. If there are a lot of use cases then this kind of makes sense. If Controllers depended on Input Ports I could easily rename Interactors or tell Controllers to use a different Input Port. And then it would actually decrease the number of changes, I just need to make Input Ports as general as possible. Thank you for putting effort explaining to me, Alex! – rasuru Dec 07 '20 at 11:42
  • Same here @rasuru. I wonder why not call Interactors directly ? – chraz Apr 07 '22 at 19:38