Interactor是一种与“业务逻辑”概念无关的设计模式。在不深入讨论细节的情况下，Interactor模式是Command pattern的扩展;每个“业务逻辑”对象都被视为一个“黑盒”，一个为客户端执行的简单指令，将调用操作的对象与知道如何执行操作的对象解耦。（详细说明请参考参考书目）。
在android环境中，有一个简单的“规则”，要求程序员在后台线程中执行长时间的任务，因此交互器模式扩展了“命令模式”，增加了一层线程。所有这些复杂的东西都是为了创建一个“干净的体系结构”，它需要一个可伸缩的、可维护的和（可以说）可理解的代码。
关于这个问题。层与层交互的设计模式是什么？它可能有不止一个正确的答案，这取决于情况。你可以使用一个简单的接口作为入口点，所以你可以使用适配器模式，或者Facade模式，或者如果你想做一些更高级的事情，你可以实现一个事件总线系统。

• 来源：Design patterns explained simply - auth Alexandria Shvets。第14页（适配器）、第32页（命令）、第47页（外观）*

在清洁架构方法中，用例交互器是表达特定业务规则的层。用例交互器与实体（不可知的业务规则）交互以实现用例意图。实体可以在另一个应用程序中使用，一旦它们是不可知的，另一方面，用例交互器是特定的应用程序对象。
可以在Robert C.第20章**

如果您熟悉领域驱动设计，那么可以将Interactor比作应用程序服务。另外，“* 按照干净的架构，设计交互器是包含所有业务逻辑的部分 ”的说法是不正确的。相反，实体将包含业务（应用程序不可知）逻辑;而Interactors将包含特定于应用程序的逻辑。交互者将调用实体来完成一个用例，其中一个用例可能是创建采购订单之类的东西。
回到使用Robert Martin（Bob叔叔）在他的培训视频Architecture, Use Cases, and High Level Design中使用的清洁架构术语，Bob叔叔说了以下内容：
交互器是特定于应用程序的。这意味着任何特定于应用程序的业务规则都属于交互器内部。交互器通过调用实体内的应用程序不可知逻辑的应用程序特定逻辑来实现其目标。例如，CreateOrderInteractor调用OrderEntity的构造函数和GetId方法。显然，这两种方法是与应用程序无关的。交互器知道如何调用这两个方法来实现用例的目标。
根据您的观察， Interactor看起来像是在两个不同的层（如数据和表示者）之间进行交互 *，该作业实际上属于Boundary。Boundary位于交付机制和Interactor之间，交付机制可能是桌面应用程序、MVC应用程序、API等。这使实际的应用程序和业务代码保持分离，并可从一种交付机制转移到另一种交付机制。
他也有一个很好的图表在额外的部分显示的互动，如果你购买的视频。它看起来像下面这样：
Delivery Mechanism ==> Boundary ==> Interactor ==> Entity
P.S.上面提到的视频非常有趣和信息。

从我所阅读到的内容来看，它相当于模型视图表示器（MVP）架构中的表示器。
它处理业务逻辑，而不是存储或显示数据。它创建独立于数据存储或显示方式或位置的单独层。它只关心任何格式的输入和输出。它可以结合Observer、Adapter和Façade模式使用，分别作为回调的接口、代码的通用扩展点和任何非UI或数据存储使用的解耦入口点。
我假设它被称为交互器，因为视图与它交互以计算值并刷新任何显示的UI元素，并且它与模型对象交互以提取数据。它还可以与数据库交互进行CRUD操作，但我认为这主要是在存储库模式中解决的，因为这不是真正的业务逻辑。

Interactors为各种用例提供实现。理想情况下，每个用例应该有一个交互器，但根据应用程序的规模可能会有所不同。
现在，为什么它对每个应用程序都没有意义呢？假设您有两个应用程序。在第一个应用程序中，您只需要读取用户。在另一个应用程序中，您只需更新同一个用户。您将有两个不同的交互器，如GetUserInteractor和UpdateUserInteractor。如果你想一想，UpdateUserInteractor对第一个应用程序来说是没有意义的（反之亦然），对吗？但是，如果两个服务（读取和更新）的实现都包含在相关业务/域对象（或作为单独的用例对象）中，则两个应用程序的业务/域逻辑仍然可以相同。这些对象显然封装了与应用程序无关的业务规则，因为它们可以插入到两个或更多不同的应用程序中。
应用程序和用户之间发生的通信通常是特定于应用程序的。正如其他人已经提到的，您可以让交互器对用户操作执行命令。或者你可以选择另一种类似的方式。但是命令模式确实很方便，可以说使整个代码更加一致、统一和易于理解。
最后但并非最不重要的是，交互器的另一个重要方面是“边界接口”，它是为输入和输出交付而部署的类。
(PS例如，在Android中，使用新的架构组件，Fragment/Activity可以被认为是输入边界的实现，因为您将输入事件传递到您的业务逻辑（或域模型）-它是控制器。LiveData更像是输出边界实现，因为它在后台使用观察者模式，并通过交互器将数据传递回UI。在这种情况下，我认为这使得ViewModel成为交互器的有力候选者，因为它接收输入事件（以及与这些事件相对应的命令），并且还包含要观察的LiveData示例。所有这些都是解耦的好，还是多态部署？这主要与你的设计有关。有了协程，现在似乎不需要回调/侦听器了--这是另一个维度。）
这是我的收入我希望它是清楚的。

这是MVP模式。是的，正如你所说，它是演示者和数据之间的中介（作为一种形式的休息呼叫或共享偏好或Sqlite）。