As per clean architecture, design Interactor is part which contains all business logic. The term Interactor is quite confusing to me. Interactor seems to me like interacting between two different layers like data and presenter.
Is it the right term to use? Can anyone please clear the purpose of Interactor? Which pattern does it follow? If Interactor is not what it seems to me then what is the design pattern for layer-layer interaction?
An Interactor is a design pattern that has nothing to do with "business logic" concept. Without going in deeper level of detail the Interactor pattern is an extension of the Command pattern; Each "business logic" object is treated as a "black box", a simple instruction to be executed for the client, decoupling the object that invokes the operation from the one that knows how to perform it. (refer to the bibliography for extended explanation).
In the android enviroment there is a simple 'rule' that demands to the programmer to do long time consuming task in a background thread, so the interactor patterns extends the "Command pattern" adding a layer of threading. All this complex stuff is implemented to create a "clean architecture" which entails a code that is scalable, maintainable and (arguably) understandable.
About the question .. ¿what is the design pattern for layer-layer interaction? It could have more than one rigth answer, depends of the situation. You could use a simple Interface as the entry point, so you could use the Adapter pattern, or maybe the Facade pattern, or if you want to do something more advanced you could implement an eventbus system.
Source: Design patterns explained simply - auth Alexander Shvets. page 14 (Adapter), page 32 (Command), page 47 (Facade)
Interactors provides implementations for various use cases. Ideally, there should be one interactor per use case but it may differ according to the scale of your application.
Now, why it doesn't make sense for every application? Imagine you have two applications. In the first app, you just need to read a user. In the other application, you just update the very same user. You would have two different interactors like GetUserInteractor and UpdateUserInteractor. If you think about it, UpdateUserInteractor would make no sense for the first application (and vice versa), right? But your business/domain logic for both applications can still be the same where the implementations of both services (read and update) are included, for example, in the regarding business/domain object (or as separate use-case objects). These objects obviously encapsulate application agnostic business rules as they can be plugged under two or more different applications.
The communication takes place between the app and users is often application-specific. As others already mentioned, you can have your interactors execute commands on user actions. Or you can go for another similar way. But the command pattern is really convenient and arguably make the whole code more consistent, uniform, and easy to understand.
Last but not least, the other important aspect of interactors are 'boundary interfaces' which are the classes that polymorphically deployed for both input and output delivery.
(PS: For example, in Android, with the new architecture components, Fragment/Activity can be thought as an implementation of the input boundary as you deliver input events down to your business logic (or domain model) - it's the controller. LiveData is more like the output boundary implementation as it uses observer pattern under the hood and deliver the data back to the UI through the interactor. In this case, I think this makes the ViewModel a strong candidate for being the interactor since it receives the input events (and commands corresponding those events) and also contains the LiveData instance to be observed. Are all these decoupled nice, or, polymorphically deployed? Well, this is mostly related to your design. And with coroutines, now it seems like there's no need for callbacks/listeners - so another dimension into this picture.)
This is my take. I hope it's clear.
From what I'm reading, it's the equivalent of the Presenter in the Model View Presenter (MVP) architecture.
It does business logic, not store or display data. It create a separate layer independent of how or where data is stored or displayed. It only cares about inputs and outputs in any format. It could be used in a combination of the Observer, Adapter, and Façade patterns to be an interface for callbacks, a generic extension point of the code, and a decoupled entry point for any non UI or data-storage usage, respectively.
I assume it is called an Interactor because the View interacts with it to calculate values and refresh any displayed UI elements and it interacts with the Model objects to extract data. It could also interact with a database for CRUD operations, but I think that's mostly addressed in the Repository Pattern as that isn't really business logic.
In the clean architecture approach, the Use Case Interactor is a layer that express the specific business rules. The Use Case Interactor interacts with the Entities (agnostic business rules) to achieve the Use Case intention. Entities can be used in another applications, once they are agnostics, on the other hand, the Use Case Interactors are specific application objects.
Can be fount at Clean Architecture book by Robert C. Martin at chapter 20
If you're familiar with domain driven design, then an Interactor can be compared to an Application Service. Also, it is incorrect to say "As per clean architecture, design Interactor is part which contains all business logic." On the contrary, Entities would contain the business (application-agnostic) logic; whereas Interactors would contain the application-specific logic. The Interactors would call the Entities to fulfill a use case, where a use case might be something like Create Purchase Order.
Going back to using Clean Architecture terms that Robert Martin (Uncle Bob) uses in his training video Architecture, Use Cases, and High Level Design, Uncle Bob says the following:
Interactors are application-specific. That means that any application specific business rule belongs inside an interactor. The interactors achieve their goals with application-specific logic that calls the application-agnostic logic within the entities. For example, the
CreateOrderInteractorinvokes both the constructor and theGetIdmethod of theOrderEntity. Clearly, these two methods are application-agnostic. It's the interactor that knows how to call those two methods to achieve the goal of the use case.
For your observation that the Interactor seems like it is interacting between two different layers like data and presenter, that job actually belongs to the Boundary. The Boundary sits between the delivery mechanism and the Interactor, where the delivery mechanism might be a desktop application, MVC app, API, etc. This keeps the actual application and business code separate and transferable from one delivery mechanism to another.
He also has a nice diagram in the Extras section showing the interaction if you purchase the video. It looks something like the following:
Delivery Mechanism ==> Boundary ==> Interactor ==> Entity
P.S. The video referenced above is highly entertaining and informational.
It's MVP pattern. Yes as you said it's mediator between presenter and data(as a form of rest call or shared preference or Sqlite).
