关闭。这个问题是opinion-based .它目前不接受答案。
想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.
11 个月前关闭。
社区在 6 个月前审查了是否重新打开此问题并将其关闭:
原始关闭原因未解决
Improve this question
我已经阅读了 PPP 书籍和干净的代码、编码器和架构书籍。
我知道:
所以我假设干净的架构不会强制关闭分层，它允许开放分层，这意味着例如框架层中的 UI 可以直接访问实体，从而跳过 2 层。
而且我知道如果干净的架构被迫紧密分层，我们不能直接从框架层实现存储库接口(interface)，我们应该在下一层的条款中实现它，而下一层应该在下一层的条款中实现它，所以在。
现在我的问题是，为什么我们不能介绍
Entity直接作为用例或 Controller 的参数类型，为什么我们必须在中间层定义数据结构或DTO，并将实体转换为数据结构并将其作为响应返回，而我们可以使用并查看Entity在 Controller 层，因为没有违反访问规则？考虑这个例子，假设我们有:
JobView JobController JobUseCase(RequestModel) : ResponseModel JobEntity 现在如果
JobView想调用JobController , 它应该通过 RequestModel .现在我们可以简单介绍JobEntity作为 RequestModel像这样:JobView JobController JobUseCase(JobEntity) JobEntity 我知道这样做会增加代码的脆弱性，因为如果我们更改
JobEntity ，然后 JobView必须改变。但是，干净的架构是否会迫使 SOLID 原则通常变得脆弱或僵化？!
最佳答案
为什么不使用实体作为用例的请求模型？
你自己已经回答了这个问题:即使你没有打破依赖规则，它也会增加代码的脆弱性。
为什么我们不能直接将实体作为用例或 Controller 的参数类型引入，为什么我们必须在中间层定义数据结构或 DTO 并费心将实体转换为数据结构并将其作为响应返回，而我们被允许使用和查看实体在Controller层因为没有违反访问规则？
(关键业务)实体和 DTO 在应用中的原因非常不同。实体应该包含关键的业务规则，并且与适配器和交互器之间的通信无关。 DTO 应该以最方便的方式实现以增强这种通信，并且没有任何直接的理由依赖业务实体。
即使一个实体可能具有与 DTO 完全相同的代码，这也应该被视为巧合，因为它们更改的原因完全不同(单一责任原则)。这似乎与流行的 DRY 原则(不要重复自己)相冲突，但 DRY 声明知识不应重复，代码在应用程序的不同部分可能仍然看起来相同，只要它们因不同的原因而更改。
关于oop - 整洁架构 : why not using the entity as request model of the use case (interactor)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52812337/