让我们分离分离

Source: Dev.to

引言

在 2025 年的最后几天，我们的团队负责人额外请了一天假，错过了一个重要会议。最近的重组后，一位同事离开了项目，两个新人加入。讨论的重点是如何为一个 Spring Boot Web 项目构建新的代码结构。

现行做法

在我大约 10 年的职业生涯中，最常见的模式是：

1. DTO POJO 位于 REST 控制器的入口/出口。
2. 实体对象 直接映射到存储模式（例如关系型数据库）。

偶尔会有仅用于业务流程的 POJO，但为简化起见这里省略不谈。工作流如下：

REST Controller
   ↔ DTO (request/response)
   ↔ Mapper
   ↔ Entity (persistence)

将请求/响应对象与存储实体分离可以使用不同的结构，并使代码在面对变化时更具前瞻性。

然而，这并没有完全将核心逻辑与仓库层解耦：对实体的任何更改都会直接影响核心。实际上，实体很少在没有相应业务需求的情况下被修改，所以我习惯只使用 DTO 和实体。

完全解耦的决定

尽管我有保留意见，团队还是决定将核心完全与仓库分离。新的布局引入了额外的映射类和复制实体的 POJO：

REST Controller
   ↔ DTO (request/response)
   ↔ Mapper (DTO ↔ Domain Model)
   ↔ Domain Model (core)
   ↔ Mapper (Domain Model ↔ Entity)
   ↔ Entity (persistence)

担忧

• 复杂度增加：类的数量增多意味着需求变更时需要修改的地方更多。
• 维护开销：随着时间推移，额外的层可能成为不必要的复杂来源。

另一方面，如果核心的内部结构与仓库的模式有显著差异，这种分离可能会有益，使每一层能够独立演进。

结论

我欢迎建设性的反馈，并愿意在额外抽象被证明有价值时进行调整。

祝大家节日快乐！