清洁架构: UseCase输出端口

Question

对于Bob叔叔的清洁建筑中的“用例输出端口”，我有一个问题。

在图中，Bob叔叔将端口描述为一个接口。我想知道是否必须这样做，或者被调用的用例交互器是否也可以返回一个“简单”值。在任何一种情况下，应用程序和业务规则层都将定义接口适配器层必须使用的接口。因此，我认为对于简单的调用来说，仅仅返回一个值并不会违反架构思想。

这是真的吗？

此外，我认为由演示者实现的输出端口接口应该像观察者模式那样工作。主持人只需观察相关“事件”的交互行为者。在.NET的例子中，事件是一流的公民，我认为使用其中之一是同样的想法。

这些想法是否与“清洁架构”背后的理念相一致？

Answer 1

豪兹特行动。我看到你的问题在这么多年之后仍然没有得到回答，我希望我们能对此作出解释，并提供一些澄清。我也希望我能正确理解你的问题。因此，考虑到这一点，下面是我对解决方案的看法：

简单的回答是，用例交互器应该能够返回一个简单的值(根据这个值，我假设字符串、int、bool等)，而不会破坏任何体系结构规则。

如果我们研究洋葱体系结构，它非常类似于干净的体系结构，其思想是将核心业务逻辑封装在体系结构的中心--域。清洁架构中相应的概念是实体和其之上的用例。我们这样做是因为我们想在编写业务规则时以一致的方式来决定我们对业务的理解。

接口适配器允许我们将外部世界转化为我们的理解。我们想要的是在我们的领域(用例或实体)的契约，以确保我们将从外部世界得到我们需要的东西，而不知道任何实现细节。我们也不在乎外界的称呼，我们把他们的理解转化为我们的理解。

这样做的一个常见方法是定义域中的接口，以建立一个契约，该契约表示，我们希望给出"x"，然后您必须告诉我们"y“是什么。然后，实现可以位于域之外。

现在来谈谈你问题的核心。让我们假设我们的应用程序的核心是跟踪一些具有不同阶段的复杂过程。在其中一个阶段，我们需要向几个外部方发送数据，并且为了审计目的，我们希望保留某种类型的引用。在这种情况下，我们的接口可能位于域中并处于状态，我们将把复杂的对象发送给某个方，我们期望返回一个字符串引用。然后我们可以使用这个字符串引用并触发一些域事件等等。实现可以完全位于域之外，调用外部API并执行它，但是我们的核心域不受影响。因此，返回一个简单的值对体系结构没有影响。上述情况的反面也可能成立。我们可以说我们有某种参照系，外面的世界需要把我们对某些事物的理解还给我们。

你问题的第二部分。我可以想象它取决于用例本身。如果您提出了一些想法，并且需要不断地对其作出反应，域事件就会介入，并且您将有一个非常类似于观察者模式的结构。.NET很好地封装了事件，并且非常适合干净的体系结构和领域驱动的设计。

请让我知道以上是否有意义，或我是否可以澄清它的任何方式。