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?
交互器是一种与“业务逻辑”概念无关的设计模式。在不深入细节的情况下，交互器模式是命令模式的扩展；每个“业务逻辑”对象都被视为一个“黑匣子”，即为客户端执行的简单指令，将调用操作的对象与知道如何执行操作的对象解耦。（有关扩展解释，请参阅参考书目）。
在 android 环境中，有一个简单的“规则”，要求程序员在后台线程中执行耗时的任务，因此交互器模式扩展了“命令模式”，增加了一层线程。所有这些复杂的东西都是为了创建一个“干净的架构”而实现的，它需要一个可扩展、可维护和（可以说）可理解的代码。
关于这个问题..¿什么是层层交互的设计模式？它可能有不止一个正确的答案，视情况而定。你可以使用一个简单的接口作为入口点，所以你可以使用适配器模式，或者可能是外观模式，或者如果你想做更高级的事情，你可以实现一个事件总线系统。
资料来源：简单解释设计模式 - auth Alexander Shvets。第 14 页（适配器）、第 32 页（命令）、第 47 页（外观）
在干净的架构方法中，用例交互器是表达特定业务规则的层。用例交互器与实体（不可知的业务规则）交互以实现用例意图。实体可以在另一个应用程序中使用，一旦它们是不可知论者，另一方面，用例交互器是特定的应用程序对象。
可以在Robert C. Martin 的 Clean Architecture 一书第 20 章找到
根据我的阅读，它相当于模型视图演示器（MVP）架构中的演示器。
它执行业务逻辑，而不是存储或显示数据。它创建一个独立的层，独立于数据的存储或显示方式或位置。它只关心任何格式的输入和输出。它可以结合使用观察者、适配器和外观模式，分别作为回调接口、代码的通用扩展点以及任何非 UI 或数据存储使用的解耦入口点。
我假设它被称为交互器，因为视图与它交互以计算值并刷新任何显示的 UI 元素，并且它与模型对象交互以提取数据。它还可以与数据库交互以进行 CRUD 操作，但我认为这主要在存储库模式中解决，因为这不是真正的业务逻辑。
如果您熟悉领域驱动设计，则可以将交互器与应用程序服务进行比较。此外，说“根据干净的架构，设计交互器是包含所有业务逻辑的部分”是不正确的。相反，实体将包含业务（与应用程序无关）逻辑；而交互器将包含特定于应用程序的逻辑。交互者将调用实体来完成一个用例，其中一个用例可能类似于创建采购订单。
回到使用 Robert Martin（鲍勃叔叔）在他的培训视频架构、用例和高级设计中使用的清洁架构术语，鲍勃叔叔说：
交互器是特定于应用程序的。这意味着任何特定于应用程序的业务规则都属于交互器。交互器使用特定于应用程序的逻辑来实现他们的目标，该逻辑调用实体内的应用程序不可知逻辑。例如，
CreateOrderInteractor调用构造函数和GetId方法OrderEntity。显然，这两种方法与应用程序无关。交互器知道如何调用这两种方法来实现用例的目标。
根据您的观察，Interactor 似乎在两个不同的层（如 data 和 Presenter）之间进行交互，该工作实际上属于Boundary. 位于Boundary交付机制和 之间Interactor，其中交付机制可能是桌面应用程序、MVC 应用程序、API 等。这使实际应用程序和业务代码保持分离并可从一种交付机制转移到另一种。
如果您购买视频，他还在附加部分中有一个很好的图表，显示了交互。它看起来像下面这样：
Delivery Mechanism ==> Boundary ==> Interactor ==> Entity
PS 上面引用的视频非常有趣和信息丰富。
交互器为各种用例提供实现。理想情况下，每个用例应该有一个交互器，但它可能会根据应用程序的规模而有所不同。
现在，为什么它对每个应用程序都没有意义？假设您有两个应用程序。在第一个应用程序中，您只需要读取用户。在另一个应用程序中，您只需更新同一个用户。您将有两个不同的交互器，例如 GetUserInteractor 和 UpdateUserInteractor。如果您考虑一下，UpdateUserInteractor对第一个应用程序没有意义（反之亦然），对吧？但是两个应用程序的业务/域逻辑仍然可以相同，其中包括两个服务的实现（读取和更新），例如，在相关的业务/域对象中（或作为单独的用例对象）。这些对象显然封装了与应用程序无关的业务规则，因为它们可以插入两个或多个不同的应用程序下。
应用程序和用户之间的通信通常是特定于应用程序的。正如其他人已经提到的，您可以让您的交互者对用户操作执行命令。或者你可以选择另一种类似的方式。但是命令模式真的很方便，可以说使整个代码更加一致、统一和易于理解。
最后但并非最不重要的一点是，交互器的另一个重要方面是“边界接口”，它们是为输入和输出传递多态部署的类。
（PS：例如，在 Android 中，使用新的架构组件，可以将 Fragment/Activity 视为输入边界的实现，因为您将输入事件传递到业务逻辑（或域模型）——它是控制器。LiveData 是更像是输出边界实现，因为它在底层使用观察者模式并通过交互器将数据传递回 UI。在这种情况下，我认为这使得 ViewModel 成为交互器的有力候选者，因为它接收输入事件（和与这些事件相对应的命令），还包含要观察的 LiveData 实例。所有这些解耦好还是多态部署？嗯，这主要与您的设计有关。使用协程，现在似乎不需要回调/listeners - 所以这张图片的另一个维度。）
这是我的看法。我希望这很清楚。
这是MVP模式。是的，正如您所说，它是演示者和数据之间的中介（作为休息电话或共享偏好或 Sqlite 的一种形式）。