📚[Spring] Scheduler Project

스프링 첫 프로젝트 SchedulerProject 가 끝났다.
요구사항 중 페이지네이션 기능과 유효성 검사 기능은 끝내 구현하지 못했다.
개발 도중 막히는 순간이 계속해서 발생했고 그때마다 추가 학습과 재개발을 반복하다 보니
마감시간이 가까워졌고 모든 요구사항을 구현하기는 힘들다고 판단했다.
그래도 첫 스프링 프로젝트인 만큼 가볍게 회고해보고 마무리하고자 한다.

---

3-tier Layered Architecture

Controller, Service, Repository 를 거치는 데이터의 흐름과 각각의 책임에 대해 깊이 고민해 볼 수 있는 시간이었다.

//Service Method
@Override
public ScheduleResponseDto findScheduleById(Long id) {
    return scheduleRepository.findScheduleById(id)
            .stream().findAny().orElseThrow(() -> new ScheduleNotFoundException("해당 id와 일치하는 일정이 없습니다."));
}

//Repository Method
@Override
    public List<ScheduleResponseDto> findScheduleById(Long id) {
        return jdbcTemplate.query("select * from schedule where scheduleId=? order by lastModifiedDate desc", scheduleMapper(), id);
    }

Repository 는 주어진 id로 쿼리를 실행하고 결과를 List<ScheduleResponseDto> 형태로 반환한다.
프로젝트를 시작할 즈음엔 쿼리 결과가 비어 있을 경우 Repository 에서 예외를 발생시키는 것이 자연스럽다고 생각했다.
하지만 각 계층의 책임에 대해 고민하다 보니 예외 처리의 책임은 Service 에 있다는 결론에 도달했다.

Repository 는 정상적으로 DB 에 접근했고 그 결과로 빈 리스트로 반환했다.
이는 단순히 해당 조건에 맞는 데이터가 없다는 의미일 뿐, Repository 는 자신의 책임을 다한 것이다.
그리고 이 결과를 받고 비즈니스 로직의 흐름에 따라 예외를 발생시킬지 그대로 처리할지는 Service 의 역할인 것이다.

이처럼 계층마다 책임을 명확히 나누는 일은 단순한 구현보다 훨씬 어렵고 많은 고민을 필요로 한다.
하지만 그런 구조적 고민과 반복이 결국 더 나은 설계를 만들어간다는 걸 이번 프로젝트를 통해 직접 느낄 수 있었다.

---

GlobalExceptionHandler

@ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler
    public ResponseEntity<ErrorResponse> handleUserNotFoundException(UserNotFoundException ex) {
        ErrorResponse response = new ErrorResponse(ex.getMessage(), HttpStatus.NOT_FOUND.value());
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body(response);
    }

    @ExceptionHandler
    public ResponseEntity<ErrorResponse> handleScheduleNotFoundException(ScheduleNotFoundException ex) {
        ErrorResponse response = new ErrorResponse(ex.getMessage(), HttpStatus.NOT_FOUND.value());
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body(response);
    }

    //인증실패
    @ExceptionHandler
    public ResponseEntity<ErrorResponse> handlePasswordMismatchException(PasswordMismatchException ex) {
        ErrorResponse response = new ErrorResponse(ex.getMessage(), HttpStatus.UNAUTHORIZED.value());
        return ResponseEntity.status(HttpStatus.UNAUTHORIZED).body(response);
    }

    //로직상 예외가 발생할 일은 없지만 예외가 터진경우 서버나 DB의 문제일 확률이 있음 500에러 리턴
    @ExceptionHandler
    public ResponseEntity<ErrorResponse> handleQueryFailedException(QueryFailedException ex) {
        ErrorResponse response = new ErrorResponse(ex.getMessage(), HttpStatus.INTERNAL_SERVER_ERROR.value());
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(response);
    }
}

@Getter
public class ErrorResponse {
    private String message;
    private int status;
    private LocalDateTime timestamp;

    public ErrorResponse(String message, int status) {
        this.message = message;
        this.status = status;
        this.timestamp = LocalDateTime.now();
    }
}

@ControllerAdvice 어노테이션을 사용해 전역 예외 처리 핸들러를 구현했다.
기존의 try-catch 방식이 아닌 컨트롤러 단에서 발생할 수 있는 예외를 중앙 집중형으로 처리하기 위한 구조이다.
불필요한 예외 클래스를 무분별하게 만들지 않도록 고민하여 프로젝트에 꼭 필요하고 생각되는 예외들만 커스텀 예외로 정의했다.
각 ExceptionHandler 는 해당 예외상황에 맞는 HTTP 상태코드와 에러 메세지를 담은 ErrorResponse 를 반환하도록 설계하였다.
기본 응답 정보만으로는 무수히 발생할 수 있는 다양한 예외 상황을 일관되게 구분하고 처리하기 어렵다.
그렇기 때문에 예외를 직접 정의하고 필요한 정보를 담아 커스텀 예외로 처리하는 것은 개발자가 주도적으로 예외 흐름을 설계하는 중요한 기술이라고 생각한다.

---

Scheduler 프로젝트

https://github.com/teopteop/SchedulerProject