Clean Architecture: Combining Interactors

Question

I\'ve recently stumbled upon Clean Architecture, by Uncle Bob, and I\'m curious to know whether Interactors can execute other Interactors.

For example, these are my Inte

Answer 1

My answer would be no. Let me explain the reasons:

1. That would be breaking boundaries

One of the most important concepts of Clean Architecture, is boundaries. Each use case defines a boundary, a vertical layer of a system. Therefore there's no reason to let a use case know about the existence of another use case. This vertical layers, allows to get independent develop-ability and deployability of the use cases. Imagine we are working as a team, you develop GetEmptyAlbums use case, and I work on the GetAllAlbums use case. If I call your use case in my own, we are not developing independently. Neither we're achieving independent deployability. The vertical boundaries breaks. See page 152 of Clean Architecture book and chapter 16 in general, for more details on that.

2. SRP would be broken too

Suppose GetEmptyAlbums business rules changes for any reason. You will be in need to refactor that use case. And now maybe you need to accept some input. If GetAllAlbums invokes GetEmptyAlbums, this use case must be refactored too. In other words, by coupling use cases you are adding more responsibilities. Therefore SRP breaks.

3. DRY is still complaint

There are 2 kinds of duplication: true duplication and accidental duplication. By defining 2 or more use cases that are very similar with each other, you're getting accidental duplication. It is accidental, because in the future the will become different probably and (this is what's matters) for different reasons. See page 154 for this concepts.

4. Tests become more fragile

Very related to SRP. If you change something on use case A, and C calls A, not only A tests will break, but C tests too.

In conclusion, the answer is no, you cannot call a use case interactor from another one. But this rule applies if you want to achieve a pure Clean Architecture approach, which not always might be the right decision.

Another thing to point out, is that use cases must declare an input and output data structures. I'm not sure if your Album class is an Entity, but if so, there's a problem there. As Uncle Bob says: "we don't want to cheat and pass Entity objects" between boundaries (page 207).