最近一次 Code Review，我和同事“打”了一架。事情的起因很简单。我发现他在 Service 层直接 return 了 Result 对象。我提醒了一句：“这个不太合适。”
同事一脸疑惑地反问我：「为啥不行？这样 Controller 直接 return，不是更省事吗？」
于是，一场看似很小、但含金量极高的技术 battle就此展开。聊着聊着我才意识到：这个问题，几乎每个写过三年以上 Java 的人都“踩过”，但真正想明白的人并不多。所以我决定把这次讨论完整拆出来，不止告诉你“不该这么写”，而是告诉你：为什么。
知其然，更要知其所以然。耐心看完，你一定会对「分层设计」有一次质变级的理解。
先抛结论
Service 层返回 Result，本质上是在“越权”。
它越过了自己的职责边界，开始关心 HTTP 返回结构、错误码、响应格式，而这些，本就不该是它操心的事。
我们一点一点拆。
第一：职责分离，被悄悄破坏了
在最经典的 MVC / 分层架构 里：
- Controller：处理 HTTP、参数、响应格式
- Service：只干一件事，业务逻辑
- DAO / Repository：数据访问
但很多项目，会慢慢演变成这样：
不推荐的写法
@Service
public class UserService {
public Result<User> getUserById(Long id) {
User user = userMapper.selectById(id);
if (user == null) {
return Result.error(404， “用户不存在”);
}
return Result.success(user);
}
}
@RestController
public class UserController {
@Autowired
private UserService userService;
@GetMapping("/user/{id}")
public Result<User> getUser(@PathVariable Long id) {
return userService.getUserById(id);
}
}
表面看：代码少，Controller 很“干净”。
但问题在于：
Service 层已经开始关心：错误码、返回结构、前端展示。
一旦哪天你要：
- 改返回格式
- 统一错误码
- 接 GraphQL / RPC
- 做内部服务复用
你会发现 改动像病毒一样，扩散到所有 Service 方法。
推荐的写法
@Service
public class UserService {
public User getUserById(Long id) {
User user = userMapper.selectById(id);
if (user == null) {
throw new BusinessException(“用户不存在”);
}
return user;
}
}
@RestController
public class UserController {
@Autowired
private UserService userService;
@GetMapping("/user/{id}")
public Result<User> getUser(@PathVariable Long id) {
return Result.success(userService.getUserById(id));
}
}
一句话：
让每一层，只关心自己的事。
第二：Service 返回 Result，复用性直接废掉
这个坑，在服务之间互相调用时，尤为明显。
Service 返回 Result 时，调用方会很痛苦
@Service
public class OrderService {
@Autowired
private UserService userService;
public void createOrder(Long userId) {
Result<User> userResult = userService.getUserById(userId);
if (!userResult.isSuccess()) {
throw new BusinessException(userResult.getMessage());
}
User user = userResult.getData();
// 后续逻辑
}
}
你会发现两个很烦的点：
- 得解包 Result
- 得理解 Result 的语义（success？code？message？）
但本质上，OrderService 只关心一件事：User 在不在。
Service 返回业务对象，调用才“像业务”
@Service
public class OrderService {
@Autowired
private UserService userService;
public void createOrder(Long userId) {
User user = userService.getUserById(userId);
// 后续逻辑
}
}
业务层之间，应该传“业务语言”，而不是 HTTP 响应协议。
第三：异常 vs Result，决定了系统的上限
很多人喜欢在 Service 里这样写：
public Result<Void> createOrder(Long userId) {
if (userId == null) {
return Result.fail(“用户ID不能为空”);
}
return Result.success();
}
短期看没问题，长期看：
- 错误处理逻辑到处都是
- 统一改异常策略成本极高
- 日志、堆栈信息丢失
正确姿势：异常 + 全局处理
public void createOrder(Long userId) {
if (userId == null) {
throw new BusinessException(“用户ID不能为空”);
}
}
@RestControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(BusinessException.class)
public Result<Void> handle(BusinessException e) {
return Result.error(400， e.getMessage());
}
}
一句话：
异常是业务失败，Result 是表现形式。
第四：单元测试，谁写谁知道
Service 返回 Result，测试写到怀疑人生
Result<User> result = userService.getUserById(1L);
assertTrue(result.isSuccess());
assertEquals(“张三”， result.getData().getName());
你明明是在测业务，却被迫关注 响应结构。
Service 返回业务对象，测试才“纯”
User user = userService.getUserById(1L);
assertEquals(“张三”， user.getName());
测试关注点瞬间清晰。
第五：从 DDD 看，这是“层污染”
在 DDD 里：
- Service / Domain 层：领域语言
- Result：基础设施 / 表现层概念
如果领域层开始 return Result，本质是：
HTTP 协议污染了领域模型。
public TransferResult transfer(...) {
// 领域行为
}
这才是领域该返回的东西。
第六：接口形态一多，问题全暴露
同一个 Service，可能被：
- REST 调用
- GraphQL 调用
- RPC 调用
如果它 return Result —— 所有接口都被强行统一成 HTTP 思维。
而返回业务对象：
Controller 想怎么包，是 Controller 的自由。
第七：事务语义，最容易被忽略的一点
@Transactional
public Order createOrder(...) {
// 失败抛异常 → 回滚
// 正常返回 → 提交
}
异常 = 回滚信号
如果你用 Result 表示失败，却不抛异常：
这在生产环境，是真·事故源头。深入理解事务控制是保证系统健壮性的关键。
总结
那天 Code Review 结束时，我跟同事说了一句话：
“Service 层一旦开始返回 Result，系统的天花板就已经被你锁死了。”
同事沉默了几秒，说：「我懂了……之前只是觉得‘方便’，没想过这些。」
送你一句架构师级祝福：
愿你
少写一点“看起来省事”的代码
多写一点“五年后还能用”的设计
毕竟，bug 和秃头，总有一个会先来。
希望这次关于 Java 分层设计的探讨，能给你带来启发。在云栈社区，我们持续分享这类有深度的技术实践，帮助开发者构建更清晰、更健壮的系统架构。
发表于 5 小时前
|
查看: 0|
回复: 0
