2021-04-26-TIL
2021-04-26-TIL
반찬 쇼핑몰 프로젝트에서 메인과 상세보기 API를 구현하고 리뷰 요청 PR을 올렸다. 아래는 PR 본문이다.
메인, 상세보기 구현
안녕하세요! team07-백엔드 반의 히로, 어거스트 입니다. 현재까지 구현한 부분에 대한 PR입니다. 상세한 피드백 부탁 드립니다. 감사합니다!
- 배포 서버 입니다
- http://13.209.36.131:8080/main
- http://13.209.36.131:8080/detail/17011200/H9881 (example)
- API document 입니다
- DB 구조 입니다
구현 내용
- 메인 페이지 출력 데이터 api 구현
- 3개의 각 카테고리에 대해서 아이템 목록을 ItemDto를 통하여 가져오도록 구현했습니다.
- Aggregate root를 Category로 하여 Item목록을 가져오도록 구현했습니다.
- ItemDto에 List필드를 가지며, 변환해주는 메소드
toList를 별도로 구현했습니다.
- 상세보기 페이지 출력 데이터 api 구현
- categoryId와 Item의 hash값을 받아서 상품 상세보기에 대한 데이터를 응답 메시지로 보냅니다.
- DetailItemDto를 통해서 json 데이터를 보냅니다.
- ItemDto와 마찬가지로 List필드에 대해서는 변환해주는 메소드 toList를 사용하여 생성합니다.
TODO
- 주문과 OAuth에 대한 부분은 추후 추가할 예정입니다.
PR에 담긴 설계 포인트
Category를 애그리거트 루트로 둔 이유
메인 페이지는 카테고리별로 상품 목록을 보여 준다. 그래서 Category를 루트로 두고 그 아래에 Item 목록을 매달면, 리포지토리에서 카테고리 하나를 읽는 것만으로 화면 한 블록에 필요한 데이터가 모인다. Spring Data JDBC는 루트를 기준으로 하위 엔티티를 함께 읽고 쓰기 때문에 이 구조와 잘 맞는다(Spring 블로그).
다만 Spring Data JDBC는 루트를 다시 저장할 때 하위 엔티티를 모두 지우고 다시 넣는다(엔티티 저장 문서). 카테고리 아래 상품이 많아지고 상품을 자주 수정한다면, 상품을 별도 애그리거트로 떼어 내고 카테고리 id로 참조하는 구조도 함께 검토해야 한다.
List 필드와 toList
상품에는 썸네일 이미지 목록, 상세 이미지 목록처럼 여러 값을 가진 필드가 있다. DB에 저장된 형태와 응답의 JSON 배열은 모양이 다르기 때문에, 응답을 만들 때 List로 모으는 변환이 필요하다. ItemDto와 DetailItemDto의 toList가 그 역할을 한다. 배열을 DB에 어떤 형태로 둘지는 배열을 데이터베이스에 저장할 때 무엇을 먼저 판단해야 하는가에 정리했다.
상세보기의 식별자
상세보기는 categoryId와 상품의 hash를 함께 받는다. 예시 URL /detail/17011200/H9881에서 앞이 카테고리 id, 뒤가 상품 hash다. 상품이 카테고리 애그리거트 안에 있으므로, 루트(카테고리)와 그 안의 상품이라는 관계가 URL에도 드러난다.
댓글
아직 댓글이 없습니다