如果 Clean Architecture 的接口适配器无法了解其所适配的基础设施的详细信息，那么它们如何才能适配接口呢？

Question

根据我对 Clean Architecture 的理解，每一层都只能直接依赖于内部层，而与外部层相关，只有抽象才允许通过 DIP 设置为依赖项。遵循这个规则，适配器层可以直接依赖于应用层，并且只能通过抽象的方式将基础设施层作为依赖。在我的概念中，这没有任何意义，因为为了使适配器能够在接口之间执行转换，它必须详细了解它正在适应哪些接口 - 不知道一侧的细节，另一侧的抽象。我对此进行了搜索，但没有找到令人信服的答案。

Answer 1

这个问题可能是清洁架构中最具争议性的问题之一，并且（据我的理解）也是六边形架构和清洁架构差异最大的问题。

Clean Architecture中的一般概念是：内层提供一个接口，由外层实现。适配器层也可以遵循这种方法。

假设您想要实现一个访问 SQL 数据库的存储库模式。然后，在适配器层中，您将实现用例层中最适合用例的接口。该接口可能具有专门针对“GetAllCustomersWithOpenOrders”或“GetOrderHistoryOfCustomer”等用例需求的 API。现在，为了实现这些 API，适配器需要访问 SQL 数据库，为此，它将再次定义一个方便适配器的接口，因此它可能会定义通用 CRUD API 以将某些 SQL 作为字符串传递。然后，该接口将由一个类在“框架和驱动程序”层中实现，该类将知道如何访问数据库（它将具有连接字符串，并且可能取决于供应商特定的数据库访问库）。

通过这种方法，可以维护干净架构的依赖规则，但它可能会引发两个问题：

1. 如果适配器构建 SQL 字符串，它不是仍然“依赖于技术”吗？是的，但适配器不一定需要技术独立，如果它独立于特定框架、供应商或外部服务。我们可以轻松地添加另一个适配器，它在用例层中定义的接口和文档数据库之间“创建一座桥梁”。

2. 如果我们在框架层还需要一个接口和一个实现，那么这样一个适配器的价值是什么？答案可能在很大程度上取决于这两个界面之间的“概念差异”。在上面的示例中，适配器仍然包含有关数据库模式、如何进行连接以及如何构建复杂查询的所有知识。框架层中的实现非常小，因为它可能只是通过供应商特定的库将 SQL 查询传递到正确的数据库实例。将数据库供应商替换为其他供应商是可能的，并且对您的应用程序的影响最小。在其他情况下，配给可能是相反的，适配器可能只是一个“数据转换”层。

就我个人而言，我仍然没有找到解决这个问题的“灵丹妙药”，所以我尝试根据具体情况做出“务实”的决定，正如我试图在我的博客文章中总结的那样：http ://www.plainionist.net/实施清洁架构框架/

更新 2022-11-08 创建了一个 YouTube 视频，进一步深入讨论了该主题：存储库模式：正确与务实？| 干净的架构