상품 목록
상품 목록
요구 사항
기획자가 아래와 같은 아주 간단한 상품 목록 기획서를 가져왔다고 가정해보겠습니다.
나였다면 기획서를 보고 어떤 질문을 했을까?
- 카테고리 조회
- 카테고리 클릭 시, 해당 카테고리에 맞는 상품 목록 조회 (최대 n개)
- 페이지 네이션 (
offset,limit) - 최신순으로 정렬 (추후 정렬은 변경 될 수 있음)
저였다면 위 요구사항을 보고 이정도 기능을 질문 없이 개발 했을 것 같습니다.
하지만, 강의에서는 이렇게 개발해서는 언된다고 합니다. 보이는 대로 개발을 진행하는 것이 아니라, 개발하기 전에 기획자에게 어떤 요구사항이 더 숨어있는지 계속해서 물어보고 질문해야 한다고 합니다.
또한, 페이징 같은 경우 프론트와의 협업도 있기 때문에 프론트에게도 질문을 해야합니다.
요구사항 더 캐묻기
- 하위 카테고리는 없는가?
- 하나의 상품은 하나의 카테고리만을 가지는가? (
1:N에서M:N관계가 되는 중요한 문제) - 카테고리는 몇 개를 보여줘야 하는가?
- 상품은 몇 개를 보여줘야 하는지?
- 스크롤 방식인지? 페이지 방식인지?
- 스크롤 할때는 몇 개씩 가져올 건지?
- 상품이 없다면 어떻게 보여줄건지?
- 카테고리 별로 최대 상품 개수가 정해져 있는지?
- 상품마다 보여주는 내용은 뭐가 있는지?
- 정렬은 어떻게 처리해야 하는지? (최신순, 마지막 수정 순, 인기순, 우선순위 등등)
- 스크롤 or 페이징에서는
커서방식으로 할지offset,limit방식으로 할지? (프론트와의 협의) - 상품이 별로 없다면 전체를 다 조회해서 프론트에서 처리 하는건 어떤지? (프론트와의 협업)
- 등등
중요한 점
최악의 개발은 질문을 하지않고 API를 만들어 주는 것입니다.
기획자가 놓친 부분을 캐치하고, 모르는 부분을 이해하려면 소통을 많이 해야 합니다.
이렇게 일을 진행해야 결과적으로 더 빠르고 원하는 결과를 얻을 수 있습니다.
API
상품 목록 조회
1
GET /v1/products
- 페이징은
offset,limit방식으로 하는 것으로 협의 되었다고 가정
| Parameter | 설명 |
|---|---|
| categoryId | 카테고리 고유 아이디 |
| offset | 시작 순번 |
| limit | 가져올 개수 |
카테고리id에 해당하는상품목록 조회
개념도
- 상품과 카테고리가
M:N관계일 때의 개념도
- 카테고리는 상품을 알지 못함
- 상품은 카테고리를 알지 못함
ProductCategory는 카테고리를 알고 있음ProductCategory는 상품을 알고 있지만, 격벽 안에 같이 있으므로 굳이 표시하지 않음
참고
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

