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