튜터님 피드백
API 설계
리마인드 알림과 웨이팅 알림의 처리 위치
Q. 예약 리마인드 알림의 경우 예약일 하루 전이니 예약쪽에서 스케쥴러를 사용하면 될 것 같은데, 웨이팅의 경우 3팀 전이라는 시점때문에 감시를 알림 쪽에서 해야하는지? 웨이팅에서 요청하는 것만 고려하면 될지?
A. 알림 서비스는 발송을 하는 주체이지 다른 서비스를 모니터링 하는 구조는 이상하다. 예약도 스케쥴러를 리마인드 알림을 하는 주체인 예약에서 진행하는게 맞을 것 같다. 웨이팅 알림처럼 특정 조건(예: 3팀 전)에 따라 감지가 필요한 건 더욱 더 웨이팅 서비스에서 자체적으로 처리하는 게 좋아 보인다.
서비스별 알림 API를 하나로 통합할지 분리할지
Q. 알림의 엔드포인트를 설정하다보니 예약 (완료, 취소, 환불) 알림을 하나의 API로 RESTful하게 통합하고 http body에서 type(enum)으로 받는 것이 좋을지? 직관적인 부분을 더 고려해 별도의 API로 나누어 구성하는게 좋을지?
A. 알림 종류별로 크게 데이터가 다르지 않다면 하나의 API로 통합하고, HTTP Body에서 타입(enum)으로 구분하는 방식도 괜찮다. 하지만 알림마다 기능이 명확히 구분되고, 독립적인 동작이 필요하다면 API를 별도로 분리하는 게 더 직관적이다.
REST 설계규칙을 지키지 않는 서비스
Q. 알림과 AI 서비스 둘 다 서비스 특성 상 GET, POST API 밖에 존재하지 않을 것 같은데, 이것은 REST 설계규칙을 지키지 않는것 같습니다. 괜찮을까요?
A. 걱정하고 있는 부분은 사용처가 명확하게 있는 API들로 구성이 이미 되었고 히스토리성 테이블이기 때문에 꼭 4종류의 Method로 구성 되지 않아도 상관없다. 다른 서비스와 다르게 생각하는 관점을 다르게 가져야한다. 오히려 무제한 적으로 늘어나는 데이터의 용량과 주기를 어떻게 가져가서 관리할지, 조회에 대한 성능을 어떻게 끌어올릴지가 중요하다.
문서 작성 가이드
서비스 구조도
주요 기능과 요청 흐름을 중심으로 이해하기 쉽게 작성해야 한다.
인프라 설계도
물리적인 환경 구성이 잘 보이도록 명확하게 그려야 한다.
팀활동
API 설계
회의
API 설계를 진행하며 명세서를 작성하고 팀원들과 컨펌 과정을 거쳤다.
서비스 기능에 대해 미처 생각하지 못했던 부분에 대해 논의를 진행했다.
- 현장 웨이팅(오프라인)도 고려할지, 예약과 웨이팅의 대기열을 공유할지 의논하고 배제하고 진행하기로 했다.
- 리마인드 알림 API의 감지 지점과 관련된 튜터님의 의견을 공유하며 예약과 웨이팅 담당 팀원과 조율을 잘 마무리했다.
협업 규칙
- DTO 클래스를 불변 객체이며 Getter와 생성자 등 롬복으로 추가했던 기능을 내장하고 있는 레코드 클래스로 도입하기로 했다.
- 엔드포인트는 REST한 방식으로 설정했다.
- 내부적으로 Builder를 사용하는 정적 팩토리 메서드를 컨벤션으로 적용했다.
네이밍 규칙
- 통신 DTO와 서비스 DTO 네이밍은 다음 규칙을 따른다. 짧게 줄이되 도메인과 Dto에 대한 명시는 추가하기로 했다.
- 예:
UserSignUpDto,UserSignUpResDto,UserSignUpReqDto
- 예:
- Enum 클래스는 마지막에 Enum을 붙이지 않고 역할에 맞는 이름만 사용한다.
- 예:
ReservationStatus
- 예:
코드 및 구조 컨벤션
- DDD 패키지 구조를 도입했다.
- JPA, 도메인, QueryDSL 레포지토리를 상속받는 구조에 대해 일부 팀원이 이해하기 어려운 점을 느껴 추가 논의를 계획했다.
- 들여쓰기, 줄 나눔 등 포맷에 대해서는 코드 리뷰 이후 발생할 문제를 다시 논의하기로 했다.
커밋 및 협업 전략
- 커밋 메시지, 브랜치 전략, PR 템플릿, 이슈 템플릿은 보통 비슷하게 사용을 했었고, 샘플 설정하고 이를 따르기로 했다.
- 에러 처리 코드와 공통 DTO(페이지 공통 DTO)는 각자 경험한 방식에 대해 논의하여 취합했고, 팀장님이 주말 동안 프로젝트 설정에 반영하기로 했다.