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

I am very new to Uncle Bob's work and I am also going through these exact same questions and problems.

My answer to maintaining the SRP and not repeating yourself (DRY) with use cases was to separate the use cases from the interactor. It's possible that this is overkill but it really worked out well for me.

I have my use cases in their own files, separated from the interactors so that all separate interactors can use whichever use cases they want and share. All the while, the interactor just "uses" (imports, depends on, etc) any use case it wants.

Doing it this way has made my interactors very simple and is really only a container for the dependency injection(s) required, and some class level member vars.

So in summary, getAllAlbums, getEmptyAlbums and getOtherAlbums use cases become their own files and follow SRP and you have an Interactor class that aggregates at will and/or stitches together use cases in sequence.

Lately I have also been making my use cases only do actual business logic and not include things from dependency injection gateways like database or network calls. I then put the code for these dependency gateway actions in the methods operating the use cases...

Now if you only have "black-boxed" business logic concepts in use cases, you can test without including the dependencies being tightly coupled. So if you we're making the game "Tic Tac Toe" for example, your use cases when (looked at in quick glance) would be talking only the language of "Tic Tac Toe" and not "save", "commit" or "fetch[X]". You can save testing those things in the interactors test or in the gateway itself.