8월 13일 (화)

참여자: 고동훤, 김준기, 김현수, 김현욱

회의 안건

• 클라이언트 ErrorCode 메시지와 서버 로깅 메시지 분리
• 비즈니스 요구사항 구체화

클라이언트 ErrorCode 메시지와 서버 로깅 메시지 분리

ErrorCode 를 도메인 단위에서 Controller 단위에서

논의 배경: 공통 Exception 을 정의하면서 기존 Controller 단위에서 사용하던 ErrorCode 가 애매해짐. 또한, 서버 로그와 클라이언트 에러 메시지를 다르게 설정하고 싶은 요구가 있음.

• 서버 에러 메시지와 클라이언트 에러 메시지를 분리하고 싶다.
  • Exception message 에 생성자로 넘겨주기
    • 이런 문자열을 상수로 관리해주고 싶다.
    • 클라이언트로의 응답과 서버 로그가 매칭이 되었으면 좋겠다.
  • 메시지의 다양성 및 변경으로 인해 테스트 코드가 빈번하게 깨질 수 있다.
    • 테스트 코드 작성시 메시지가 아니라 ErrorCode로 검증을 수행하자.

컨트롤러 반환 타입 - DTO vs ResponseEntity 재논의

이전 회의에서 ResponseEntity로 반환하도록 결정한 이유는 다음과 같다.

• DTO를 반환하도록하면, RestControllerAdvice에서 ResponsEntity로 매핑하는 로직이 필요함
• 이 때, 성공 상태코드를 세분화 (200, 201)하기 어렵다고 판단함
• 따라서 ResponseEntity 를 반환하도록 결정

재논의 하는 배경은 다음과 같다.

• 컨트롤러의 메서드에 @HttpStatus로 상태코드를 지정할 수 있다.
• 따라서, 기존에 어렵다고 생각된 이유는 해결되었고, DTO를 반환하는 형식의 구조적 간결성이 장점이라 생각들어 재논의
• 예외 처리를 ExceptionHandler에게 위임함으로서, 응답를 컨트롤러에서 동적으로 처리할 필요가 없어짐. 따라서 ResponseEntity를 반환할 필요성가 없어짐

DTO 반환 시 장단점

• DTO 반환 시 장점:

  1. 컨트롤러의 구조적 간결성과 ResponseEntity 설정 로직의 응집도 향상.
  2. 컨트롤러 단위 테스트가 용이함.

• DTO 반환 시 단점

  1. 커스텀 헤더가 존재한다면 처리하기 까다로워질 수 있다.
  2. 하지만 우리 서비스에서는 아직까지 커스텀헤더를 넣을일이 없기 때문에 현재까지는 큰 단점이 아니다.

결론

• Controller에서는 @ResponseStatus로 상태값을 정의하고 ResponseDTO를 반환하도록하고, RestControllerAdvice에서 공통적으로 API Format에 맞게 매핑해주도록 설계하기.

비즈니스 요구사항 구체화

가게 위치 정보, 식별 정보

회원 가입 시, 계좌 트랜잭션