4.5주차 과제: 화면 분석

[airoca]

✅ ERD

▶️ Entity 도출 과정과 그 이유

• 화면 분석 후 가게, 메뉴, 메뉴 옵션, 쿠폰, 카테고리, 리뷰 Entity를 도출하였다.
• 사용자(User)와 관련된 Entity는 도출하지 않았다. (ERD 단순화를 위해)
• 배달비, 배달 시간과 관련된 Entity 또한 도출하지 않았다. (이 또한 ERD 단순화를 위해)
• 최대한 단순하게 ERD를 작성하기 위해, 배달의 민족 서비스를 고려하지 않고 예시 화면만을 고려하였다.

▶️ Category 테이블 분리

카테고리를 가게 테이블의 ENUM 컬럼으로 구현할 수도 있었지만, 크게 아래와 같은 두 가지 이유로 테이블을 분리하였다.

(카테고리와 음식점이 M:N 관계라는 점은 차치했을 때)

• 카테고리는 변경될 수 있는 값이기에 확장성을 고려해야 한다.
• 카테고리에 대한 추가적인 정보(화면 기준으로는 카테고리 이미지)를 저장할 수 있다.
• 성능 Trade-off가 발생할 수 있지만, 설계 단계에서는 최적화보다 안정성을 고려하는 것이 나은 방향이라고 생각하였다.

▶️ Review 테이블 분리

화면에 직접적으로 나타나지 않은 대상은 최대한 ERD에 포함하지 않고자 했지만, 가게의 “별점” 속성에 대해 얘기해보기 위해서는 리뷰 테이블이 필요하다고 판단하였다.

• 리뷰 테이블을 통해 평균 별점을 계산하지만, 가게에도 평균 별점 컬럼을 넣었다.
• 가게 정보를 조회할 때마다 리뷰 테이블을 통한 평균 별점 집계가 일어나게 되면 성능 이슈가 발생할 수 있다고 생각했다.
• 결과적으로, 정기적으로 가게 정보의 평균 별점을 업데이트 하는 방식을 선택했다. 이 또한 일관성에 대한 Trade-off가 발생하지만, 업데이트 주기에 따라 데이터 불일치가 크지 않도록 관리 가능하다고 생각했다.

---

✅ 예시 API

API는 크게 고민하지 않고 간단하게 작성했다.

엔드포인트	설명	HTTP 메서드
/api/categories	모든 음식 카테고리 조회	GET
/api/stores/{storeId}	특정 음식점의 정보 조회	GET
/api/stores/{storeId}/menus	특정 음식점의 메뉴 목록 조회	GET
/api/stores/{storeId}/menus/{menuId}/options	특정 음식점의 특정 메뉴 옵션 조회	GET