干净的体系结构：控制器和演示器应该始终是独立的类，或者可以是相同的？

Question

我理解Clean架构中控制器和演示器的目的，我所说的不是用例应该调用控制器来显示数据（或者，至少，知道它必须调用控制器），而是假设我们已经以这种方式设置了应用程序的接口部分：（伪代码）

interface OutputPort {
    + present(response: Response)
}

interface InputPort {
    + run(data: inptuData)
}

class UseCase implements InputPort  {
    - presenter: OutputPort

    + run(data: InputData) {
        ...
        response: Response = ...
        this.presenter.present(response)
    }
}

class Presenter implements OutputPort {
    + present(response: Response) {
        ...
    }
}

class Controller {

    - presenter: Presenter;

    + executeUseCase() {
        data: InputData = ...
        useCase: UseCase = UseCase(presenter)
        useCase.run(data)
    }
}

class Controller implements OutputPort {

    + present(response: Response) {
        ...
    }

    + executeUseCase() {
        data: InputData = ...
        useCase: UseCase = UseCase(this)
        useCase.run(data)
    }
}

只是为了SRP的目的还是有其他原因？假设controller和Presenter足够短，并且使用了相同的对象，在代码需要拆分之前，在一个类中维护这两个实现不值得吗？

我的意思是，每次我们谈论干净的体系结构时，我们通常会想到web应用程序或移动应用程序，在这些应用程序中，与外部世界的交互总是用户和UI，所以在这种情况下，很明显，将这两个类分开维护是一个好处。但是假设外部参与者是一个外部API，它可以发送一个信号来通知我们执行一个操作，并且应该根据所执行的操作接收信号。在这种情况下，如果我创建了一个单独的控制器和演示器，我应该给两个外部API提供一个引用：控制器让他监听信号并触发用例，演示器让他在用例结束时向API发送信号。考虑到这种交互的简单性，让控制器和演示者是同一个类（尽管仍然实现了一个单独的接口，以便将来分开），以避免在应用程序中传播外部API的知识，这不是更好吗？

Answer 1

首先，在这两种情况下，您的依赖关系都符合clean架构。

假设controller和Presenter足够短，并且使用了相同的对象，在代码需要拆分之前，在一个类中维护这两个实现不值得吗？

您可以这样做，但如果将两者分开，它们可能更容易测试。因为当您想要测试演示者逻辑时，您不需要设置控制器的依赖项，反之亦然。

下面是我绘制的图表，以显示如何在消息传递环境中应用clean架构。例如。JMS.如果外部绝对不是用户界面，这将是一个架构。当然，MessageProducer应该使用演示器或序列化器或您所称的任何东西来创建传出消息。这是一幅古老的画。也许什么时候我会改的。

只要您遵守清洁体系结构的依赖规则，您就可以轻松地替换向外部展示用例的方式。