Why Service Layer Should Not Return a Result Object in Java

Responsibility Separation

In a traditional MVC architecture the Service layer is responsible for business logic while the Controller handles HTTP request/response formatting. Returning a Result<User> from the Service mixes presentation concerns into business code, coupling the two layers and reducing clarity and maintainability.

@Service
public class UserService {
    public Result<User> getUserById(Long id) {
        User user = userMapper.selectById(id);
        if (user == null) {
            return Result.error(404, "User not found");
        }
        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);
    }
}

A cleaner approach lets the Service return the domain object and lets the Controller wrap it into a Result when needed.

@Service
public class UserService {
    public User getUserById(Long id) {
        User user = userMapper.selectById(id);
        if (user == null) {
            throw new BusinessException("User not found");
        }
        return user;
    }
}

@RestController
public class UserController {
    @Autowired
    private UserService userService;
    @GetMapping("/user/{id}")
    public Result<User> getUser(@PathVariable Long id) {
        User user = userService.getUserById(id);
        return Result.success(user);
    }
}

Reusability Issues

When a Service returns a Result, callers must unpack it, adding boilerplate and coupling them to the response format. The following example shows an Order service that has to unwrap a Result<User> from a User service.

@Service
public class OrderService {
    @Autowired
    private UserService userService;
    public void createOrder(Long userId, OrderDTO orderDTO) {
        // Not recommended: need to unpack Result
        Result<User> userResult = userService.getUserById(userId);
        if (!userResult.isSuccess()) {
            throw new BusinessException(userResult.getMessage());
        }
        User user = userResult.getData();
        // subsequent business logic
        validateUserStatus(user);
        // ...
    }
}

Returning the pure business object eliminates the extra steps.

@Service
public class OrderService {
    @Autowired
    private UserService userService;
    public void createOrder(Long userId, OrderDTO orderDTO) {
        // Recommended: directly get business object
        User user = userService.getUserById(userId);
        // subsequent business logic
        validateUserStatus(user);
        // ...
    }
}

Exception Handling

Using Result.fail(...) for error cases forces every method to repeat error‑checking code. Throwing exceptions and handling them centrally with a global exception handler makes the code shorter and keeps error handling in one place.

public Result<Void> createOrder(Long userId, OrderDTO orderDTO) {
    if (userId == null) {
        return Result.fail("User ID cannot be null");
    }
    // subsequent business logic
    return Result.success();
}

Better:

public void createOrder(Long userId, OrderDTO orderDTO) {
    if (userId == null) {
        throw new BusinessException("User ID cannot be null");
    }
    // subsequent business logic
}

Global handler:

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(BusinessException.class)
    public Result<Void> handleBusinessException(BusinessException e) {
        return Result.error(400, e.getMessage());
    }

    @ExceptionHandler(Exception.class)
    public Result<Void> handleException(Exception e) {
        log.error("System error", e);
        return Result.error(500, "System busy");
    }
}

Testing Convenience

When the Service returns a domain object, unit tests can directly assert on that object. If the Service returns a Result, tests must unpack the wrapper, making them more verbose.

@SpringBootTest
public class UserServiceTest {
    @Autowired
    private UserService userService;

    @Test
    public void testGetUserById() {
        // Recommended: directly assert business object
        User user = userService.getUserById(1L);
        assertNotNull(user);
        assertEquals("Zhang San", user.getName());
    }

    @Test
    public void testGetUserById_NotFound() {
        // Recommended: assert exception thrown
        assertThrows(BusinessException.class, () -> {
            userService.getUserById(999L);
        });
    }
}

With Result the test becomes longer:

@Test
public void testGetUserById() {
    // Not recommended: need to unpack Result
    Result<User> result = userService.getUserById(1L);
    assertTrue(result.isSuccess());
    assertNotNull(result.getData());
    assertEquals("Zhang San", result.getData().getName());
}

Domain‑Driven Design Perspective

In DDD the Service belongs to the application or domain layer and should return domain objects. Result is an infrastructure concern (HTTP response) and should not leak into the domain layer.

@Service
public class TransferService {
    public TransferResult transfer(Long fromAccountId, Long toAccountId, BigDecimal amount) {
        Account fromAccount = accountRepository.findById(fromAccountId);
        Account toAccount = accountRepository.findById(toAccountId);
        fromAccount.deduct(amount);
        toAccount.deposit(amount);
        accountRepository.save(fromAccount);
        accountRepository.save(toAccount);
        return new TransferResult(fromAccount, toAccount, amount);
    }
}

Interface Adaptability

Returning pure business objects lets different interfaces (REST, GraphQL, RPC) adapt the response format independently.

@RestController
@RequestMapping("/api")
public class UserController {
    @Autowired
    private UserService userService;

    // REST returns Result
    @GetMapping("/user/{id}")
    public Result<User> getUser(@PathVariable Long id) {
        User user = userService.getUserById(id);
        return Result.success(user);
    }

    // GraphQL returns object directly
    @QueryMapping
    public User user(@Argument Long id) {
        return userService.getUserById(id);
    }

    // RPC returns custom DTO
    @DubboService
    public class UserRpcServiceImpl implements UserRpcService {
        public UserDTO getUserById(Long id) {
            User user = userService.getUserById(id);
            return convertToDTO(user);
        }
    }
}

The same Service method can be reused by multiple interfaces, each formatting the response as required.

Clear Transaction Boundaries

When a Service method is annotated with @Transactional, a normal return commits the transaction while an exception triggers a rollback. Returning a Result obscures this semantics because a failure may be expressed as a successful return value.

@Service
public class OrderService {
    @Transactional
    public Order createOrder(OrderDTO orderDTO) {
        Order order = new Order();
        // set order properties
        orderMapper.insert(order);
        // deduct inventory
        inventoryService.deduct(orderDTO.getProductId(), orderDTO.getQuantity());
        return order;
    }
}

If the method returns a Result, the transaction may commit even when inventory is insufficient, leading to data inconsistency.

public Result<Order> createOrder(OrderDTO orderDTO) {
    Order order = new Order();
    orderMapper.insert(order);
    Result<Void> inventoryResult = inventoryService.deduct(orderDTO.getProductId(), orderDTO.getQuantity());
    if (!inventoryResult.isSuccess()) {
        return Result.fail("Insufficient inventory");
    }
    return Result.success(order);
}

Using exceptions makes the rollback semantics explicit and avoids hidden failures.