清洁架构：用例输出端口

Posted 2023-02-23

【中文标题】清洁架构：用例输出端口

【英文标题】：Clean Architecture: UseCase Output Port

【发布时间】：2016-09-17 14:56:18

【问题描述】：

我对 Bob 叔叔的Clean Architecture 中的“用例输出端口”有疑问。

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

这是真的吗？

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

这些想法是否与清洁架构背后的想法兼容？

【参考方案1】：

Howzit OP。这些年来，我看到您的问题仍未得到解答，我希望我们可以对此进行推理并提供一些说明。我也希望我能正确理解你的问题。因此，考虑到这一点，这是我对解决方案的看法：

简短的回答是，用例交互器应该能够在不违反任何架构规则的情况下返回一个简单的值（我假设是字符串、int、bool 等）。

如果我们回顾一下与干净架构非常相似的洋葱架构，其思想是将核心业务逻辑封装在架构的中心，即领域。干净架构中的相应概念是实体和其上的用例。我们这样做是因为我们希望在编写业务规则时以一致的方式规定我们对业务的理解。

接口适配器允许我们将外部世界转换为我们的理解。我们想要的是我们领域（用例或实体）中的合同，它确保我们可以从外部世界获得我们需要的东西，而无需了解任何实施细节。我们也不在乎外界如何称呼它，我们将他们的理解转化为我们的理解。

执行此操作的一种常见方法是在域中定义接口以建立合约，该合约说，我们期望给出“x”，然后您必须告诉我们“y”是什么。然后实现可以位于域之外。

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

关于你问题的第二部分。我想这取决于用例本身。如果你提出一些想法并且需要不断地对其做出反应，那么领域事件就会参与进来，并且你将拥有一个非常类似于观察者模式的结构。 .NET 很好地封装了事件，非常适合简洁的架构和领域驱动的设计。

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