oop - 清洁架构 : UseCase Output Port

Question

我有一个关于 Uncle Bob 的“用例输出端口”的问题 Clean Architecture .

在图像中，鲍勃叔叔将端口描述为接口(interface)。我想知道是否必须这样，或者调用的用例交互器是否也可以返回“简单”值。在任何一种情况下，应用程序和业务规则层都将定义接口(interface)适配器层必须使用的接口(interface)。所以我认为对于简单的调用，只返回一个值不会违反架构理念。

真的吗？

此外，我认为演示者实现的这个输出端口接口(interface)应该像观察者模式一样工作。演示者只是观察交互者的相关“事件”。在 .NET 事件是一等公民的情况下，我认为使用其中一个是相同的想法。

这些想法是否与 Clean Architecture 背后的想法兼容？

Answer 1

Howzit OP。我看到这些年来您的问题仍未得到解答，我希望我们可以对此进行推理并提供一些清晰度。我也希望我能正确理解你的问题。因此，考虑到这一点，以下是我对解决方案的看法:
简短的回答是，用例交互器应该能够在不违反任何架构规则的情况下返回一个简单的值(我假设是字符串、int、bool 等)。
如果我们回顾一下洋葱架构，它与干净架构非常相似，其想法是将核心业务逻辑封装在架构的中心，即域。干净架构中的相应概念是实体和其上的用例。我们这样做是因为我们希望在编写业务规则时以一致的方式决定我们对业务的理解。
接口(interface)适配器允许我们将外部世界转换为我们的理解。我们想要的是我们领域(用例或实体)中的契约，以确保我们从外部世界获得我们需要的东西，而无需知道任何实现细节。我们也不在乎外界怎么称呼它，我们将他们的理解转化为我们的理解。
一种常见的方法是在域中定义接口(interface)以建立一个约定，我们期望给出“x”，然后您必须告诉我们“y”是什么。然后该实现可以位于域之外。
现在进入你问题的核心。让我们假设我们的应用程序的核心是跟踪一些具有各个阶段的复杂过程。在其中一个阶段，我们需要将数据发送给几个外部方，并且我们希望保留某种引用以用于审计目的。在这种情况下，我们的接口(interface)可能位于我们将复杂对象发送给某个方的域和状态中，并且我们期望返回一个字符串引用。然后我们可以使用这个字符串引用并触发一些域事件等。实现可以完全位于域之外并调用外部 API 并做它的事情，但我们的核心域不受影响。因此，返回一个简单的值对架构没有影响。上述情况的相反情况也可能成立。我们可以说我们有某种类型的引用 id，外部世界需要返回我们对某个对象的理解。
对于你问题的第二部分。我想这取决于用例本身。如果您提出一些想法并需要不断对其使用react，就会涉及领域事件，并且您将拥有与观察者模式非常相似的结构。 .NET 很好地封装了事件，非常适合干净的架构和领域驱动的设计。
请让我知道上述内容是否有意义，或者我是否可以以任何方式对其进行澄清。