我已经阅读了PPP书以及干净的代码，编码器和体系结构书。
我知道:
因此，我认为干净的体系结构不会强制分层，而允许分层。也就是说，例如，位于框架层的UI可以直接访问Entity，从而跳过2层。
而且我了解到，如果干净的体系结构被迫紧密地分层，那么我们将无法直接从Frameworks层实现存储库接口(interface)，而应该在下一层实现它，而下一层应该在下一层实现它，因此上。
现在我的问题是，为什么我们不能直接将
Entity引入用例或 Controller 的参数类型，为什么我们必须在中间层中定义数据结构或DTO并烦扰将实体转换为数据结构并将其作为响应返回，虽然我们被允许使用并在 Controller 层中查看Entity，因为未违反访问规则？考虑这个例子，假设我们有:
JobView JobController JobUseCase(RequestModel) : ResponseModel JobEntity 现在，如果
JobView要调用JobController，则应传递RequestModel。现在，我们可以简单地将JobEntity像RequestModel一样引入:JobView JobController JobUseCase(JobEntity) JobEntity 我知道这样做会增加代码的脆弱性，因为如果我们更改
JobEntity，则JobView必须更改。但是，干净的体系结构是否会强制SOLID原则变得脆弱或僵化？ 最佳答案
为什么不使用实体作为用例的请求模型？
您已经亲自回答了这个问题:即使您没有违反依赖关系规则，也会增加代码的脆弱性。
为什么我们不能直接将Entity作为用例或 Controller 的参数类型引入，为什么我们必须在中间层中定义数据结构或DTO并烦扰将实体转换为数据结构并将其作为响应返回，而我们却被允许使用和查看是否在Controller层中存在实体，因为未违反访问规则？
(关键业务)实体和DTO在应用上有非常不同的原因。实体应该包含关键的业务规则，并且与适配器和交互器之间的通信无关。应该以最方便的方式来实现DTO，以增强这种通信，并且没有任何直接理由依赖业务实体。
即使一个实体可能具有与DTO完全相同的代码，这也应被视为巧合，因为它们更改的原因完全不同(单一责任原则)。这似乎与流行的DRY原理相冲突(请不要重复自己)，但是DRY声明不应重复知识，只要应用程序因不同原因而被更改，代码在应用程序的不同部分中看起来仍然可能相同。