<2025.04.22> 배달 기능 프로젝트 피드백

✅ 배달 기능 프로젝트 S.A 작성에 대한 피드백

 - 와이어 프레임, ERD , API 명세서를 작성하여 피드백을 받아보았습니다.

---

와이어프레임

• 와이어프레임은 힘을 조금 빼고
• 유스케이스 다이어그램 or 클래스 다이어그램 그려오는 거 추천(다음 팀플부터)

ERD

• 주문 테이블에 있는 중복 사용자 ID 지우기
• 리뷰 테이블이 주문 ID만 가지고 있어도 다른 테이블 데이터를 알 수 있지만, 조회할 때 주문 데이터를 거쳐서 그 외 데이터를 조회하는 것보다 아예 다른 테이블을 필드로 가지고 있는 것도 설계상 괜찮다.
  • 특정 주문에 해당하는 리뷰가 필요하다면 주문만 가지고 있기
  • 다른 루트로도 리뷰를 조회하고 싶다면 다른 테이블을 가지고 있기
  • 조회가 대부분인 경우에는 매번 조인해서 데이터를 조회하는 게 성능에 좋지 않을 수 있어서 중복되는 정보를 가지고 있더라도 다른 테이블을 가지고 있는 게 나을 수 있다.
  • 처음엔 주문만 가지고 있고, 추후에 리팩토링하는 게 실력 향상에 도움 된다.
• 주문 테이블이 메뉴 테이블과 관계 가져야 한다.
• varchar 데이터 크기 명확하게 지정하기
• discription 더 정확히 하면 포폴에 도움이 된다.(어떤 용도의 컬럼인지 설명)

API 명세

• API 명세서 담당자, 진행 상태 컬럼 추가
• 요청 실패했을 때 반환할 메세지 포맷 동일하게 설정해서 명세서에 명시하기
  • 제네릭 타입 활용
• 명세서에 데이터 타입도 명시
• 추후에는 클라이언트 입장에서 언더바 사용이 좋지만, 지금은 카멜케이스로 사용하는데 컨트롤러에서 처리하기 좋음
• 메뉴 조회 API /stores/{storeId}/menus 로 변경하는게 RESTful
• hard delete인지, soft delete인지 명시 필요
• 가게 전체 조회는 쿼리 스트링 사용
• 인증, 인가 어떤 방식으로 할지(세션 or jwt / 쿠키에 넣을지, 헤더에 넣을지, 바디에 넣을지 / 키의 형태) 명시 필요

---

🔎 관련 도움 링크

 

**https://developer.spotify.com/documentation/web-api/tutorials/getting-started**

 추천 API 명세서

**https://wikidocs.net/205323**