Oop 干净的体系结构：为什么不使用实体作为用例（interactor）的请求模型

我已经阅读了PPP书籍和干净的代码，编码器和架构书籍

我知道：

• 清洁体系结构是一种分层体系结构
• 开放式分层体系结构和封闭式分层体系结构是什么样的
• 清洁体系结构书籍建议，每一层都可以访问它的内层，而不仅仅是下一层

因此，我假设clean架构不强制进行紧密分层，它允许进行开放分层，这意味着，例如，框架层中的UI可以直接访问实体，中途跳过两层

我理解，如果干净的体系结构被强制进行紧密分层，我们不能直接从框架层实现存储库接口，我们应该在下一层实现它，而下一层应该在下一层实现它，等等

现在我的问题是，为什么我们不能直接将<代码>实体< /> >作为USECASE或控制器的参数类型，为什么我们必须在中间层中定义数据结构或DTOs，并麻烦地将实体转换为数据结构，并将其作为响应返回，虽然我们被允许在控制器层中使用并查看

实体

，因为没有违反访问规则

考虑这个例子，假设我们有：

• JobView

• JobController

• JobUseCase（RequestModel）：ResponseModel

• JobEntity

现在，如果

JobView

想要调用

JobController

，它应该传递

RequestModel

。现在我们可以简单地介绍一下

JobEntity

作为

RequestModel

，如下所示：

• JobView

• JobController

• JobUseCase（JobEntity）

• JobEntity

---

我知道这样做会增加代码的脆弱性，因为如果我们改变

JobEntity

，那么

JobView

就必须改变。但干净的建筑是否会迫使坚实的原则变得脆弱或僵化

我不太明白你问题背后的原因：

干净的建筑是强制执行坚实的原则，还是不脆弱或僵化

清洁的建筑怎么可能迫使僵化和脆弱？定义架构的全部内容是：如何广泛关注基本的OOP原则，如SOLID和其他

另一方面，以下示例肯定会改变Clean体系结构：

作业视图

作业控制器
作业用例（作业实体）
作业实体

这隐式地告诉我们，您很可能从控制器中检索到了实体，这完全忽略了交互程序（或用例）以及干净体系结构的要点

交互者封装应用程序业务规则，例如通过实体网关完成的与实体的交互和实体上的CRUD，而实体网关又封装了基础架构层

此外，在干净的体系结构上下文中，作为模型层一部分的实体应该与作为交付机制一部分的控制器无关，或者更准确地说，与作为HTTP请求消息求值器的控制器无关。以这种方式变性作为控制器的较低级别组件将对SRP（=>脆弱性增加）和组件之间的解耦程度（=>刚性增加）产生负面影响


你说：

我理解，如果干净的体系结构被强制进行紧密分层，我们不能直接从框架层实现存储库接口，我们应该在下一层实现它，而下一层应该在下一层实现它，等等

您的实体框架的
RepositoryInterface
及其实现属于基础架构层，应该由实体网关进行包装和调整。在这里，当我们讨论业务模型的封闭层端口（
EntityGatewayInterface
）的实现时，尊重这一点可能很重要


最后，出于上述原因，我怀疑以下假设是错误的，基于该假设的所有进一步假设也是错误的，从而导致您完全困惑：

因此，我假设clean架构不强制进行紧密分层，它允许进行开放分层，这意味着，例如，框架层中的UI可以直接访问实体，中途跳过两层

但无论是否强制封闭分层，Clean架构都明确具体地定义了自身（组件之间的关系），如下面的UML类图所示：


从该图中，我只能看到一个紧密分层的架构

在我看来，一个开放层是一个oxymore，它并不约束一个层本质上应该约束的东西，因为根据定义，一个层是一个隔离，一组简化到其端口的组件的抽象，旨在减少技术债务，如脆弱性等


额外资源

Bob叔叔召开的会议恢复得很好为什么以及如何实施清洁体系结构：
为什么不使用实体作为用例的请求模型？

您自己已经回答了这个问题：即使您没有违反依赖性规则，它也会增加代码的脆弱性

为什么我们不能直接将实体作为USECASE或控制器的参数类型，以及为什么我们必须在中间层和BO中定义数据结构或DTOs