상품 상세
요구사항
- 상품 이미지
- 상품 이름
- 간단한 정보, 가격
- 별점, 리뷰 개수
- 상품과 연관된 다운로드 가능한 쿠폰
- 찜하기, 리뷰, Q&A 버튼
- 전체 정보 (이미지 혹은 HTML)
요구사항 더 캐묻기
- 상품 이미지는 몇 개 인지?
- 간단한 정보에는 어떤 정보가 들어가는지?
- 가격은 어떤 식으로 표기되는지? (원가, 판매가, 할인 정보 등)
- 쿠폰은 어떤식으로 보여지는지?
- 전체 정보에는 어떤 정보가 들어가는지?
- 등등
여러 개념(도메인)이 있을 때 어떻게 구현할 것인가?
상품, 리뷰, 쿠폰 등 모든 걸 한번에 내려주는 전체 API를 만들수도 있고, 상품, 리뷰, 쿠폰 별로 각각 API를 만들어 내려줄 수도 있습니다.
리뷰 같은 경우는 상품에 항상 보여지는 항목이라 상품 조회 시, 같이 내려주는 것이 자연스럽지만 쿠폰 같은 경우는 클릭 했을 때 보여질수도 있고 정책이 자주 변할 수도 있으니 별도의 API로 만들어 내려주는 것이 자연스러울수도 있습니다.
프론트와의 협의를 통해 전체 API로 내려줄지, API를 분리하여 내려줄지 정하면 됩니다.
기본적으로는 개념(도메인) 단위로 묶어주는 것이 재사용성이 좋습니다.
API를 합쳐서 내려줄지 분리하여 내려줄지의 문제지, 백엔드 비즈니스 로직은 개념(도메인) 단위로 묶어 로직을 작성하는 것이 좋습니다.
구현 시, 의존성을 어떻게 관리할 것인가
저는 처음에 ProductDetailService를 만들어 그 안에 상품, 리뷰, 쿠폰을 조회 모두 조회하여 응답으로 내려줄 생각을 했습니다.
하지만, 강의에서는 상품, 리뷰, 쿠폰 각각 서비스를 만들어 ProductController에서 조립하여 응답을 내려주었습니다.
상품 상세는 많은 개념(도메인)들이 합쳐져 만들어 집니다. 따라서 ProductDetailService에서 모두 조회 후 응답을 내려줄 경우 ProductDetailService는 모든 개념(도메인)을 알고 있는 GOD 클래스가 되어버린다는 단점이 있습니다.
하지만 ProductController에서 각각 개념(도메인)을 조회하여 조립하면 상품은 다른 개념(도메인)에 의존하지 않는 독립적인 상태로 만들수가 있게 됩니다.
강의를 보고 나니 ProductController에서 조립하여 내려주는 방향성이 더 좋다고 느꼈습니다.
API
상품 상세 조회
1
GET /v1/products/{productId}
| Path Parameter | 설명 |
|---|---|
| productId | 상품 고유 아이디 |
상품id에 해당하는상품조회상품id에 해당하는상품 섹션조회상품id에 해당하는리뷰통계 조회상품및 해당상품 카테고리에 사용 가능한쿠폰조회 (별도의 API로 빼도 괜찮을 듯)
개념도
ProductSection은 Full Information에서 보여질 이미지 혹은 HTML 리스트입니다.
- 상품, 리뷰, 쿠폰은 서로의 존재를 모름
ProductSection은 사실 물어볼 가치가 없는 상태라 개념도에서 빠져도 괜찮음