oop - 整洁架构 : why not using the entity as request model of the use case (interactor)

Question

关闭。这个问题是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 原则通常变得脆弱或僵化？!

Answer 1

为什么不使用实体作为用例的请求模型？

你自己已经回答了这个问题:即使你没有打破依赖规则，它也会增加代码的脆弱性。

为什么我们不能直接将实体作为用例或 Controller 的参数类型引入，为什么我们必须在中间层定义数据结构或 DTO 并费心将实体转换为数据结构并将其作为响应返回，而我们被允许使用和查看实体在Controller层因为没有违反访问规则？

(关键业务)实体和 DTO 在应用中的原因非常不同。实体应该包含关键的业务规则，并且与适配器和交互器之间的通信无关。 DTO 应该以最方便的方式实现以增强这种通信，并且没有任何直接的理由依赖业务实体。

即使一个实体可能具有与 DTO 完全相同的代码，这也应该被视为巧合，因为它们更改的原因完全不同(单一责任原则)。这似乎与流行的 DRY 原则(不要重复自己)相冲突，但 DRY 声明知识不应重复，代码在应用程序的不同部分可能仍然看起来相同，只要它们因不同的原因而更改。