오늘은 어제에 이어 erd랑 api를 작업했다.
이런식으로 우선 심화같은 과정을 뺀 필수 erd를 얼추 완성했는데, 이것도 너무 많아서 줄인 결과였다. 그런데도 너무 많아서 못할수도 있다는 말을 들었다. 그래서 우선 할수있는 것부터 우선 구현해보기로 하고 api를 만들었는데,
우선 미완성인 채로 들고갔더니
공구정책들을 생각해보면, 그 데이터들을 상품(프로덕트)에서 관리를 하지는 않을 것 같다.
A상품을 다른 회사에서 또 공구를 할 수 있지 않나?
공구를 관리하는 하나의 엔터티가 생기고 거기에서 프로덕트들을 관리하도록 생기는 게 맞는 것 같다.
product_limit, time_limit 도 A상품이 어떤 딜에서는 오늘까지일 수 있고, 내일 모레일 수도 있지 않을까?
-> 딜을 관리하는 엔터티를 만들고 그 안에 상품들을 관리할 수 있게 만들어라
단건상품조회는 멀티파트파일이 아니라 이미지url처럼 경로를 넣는게 맞다.
-> 상품등록에서 이미지업로드를 하려나 본데, 상품 등록과 이미지등록은 별개의 api가 되어야 한다.
해보면 알텐데 클라이언트 화면에서 멀티파트이미지를 갖고 스토리지에 업로드요청을 하게 되어 있다. (저는 몰루는데요ㅠ)
원래 상품 등록요청을 하고, 저런 데이터들을 테이블에 저장만 해주고 끝일텐데, 이미지를 요청한다던가 그런건 따로 하지 않는다는것.
그래서 이미지등록 api가 따로 있어야 함.
요청이랑 응답값에서도 멀티미디어가 빠져야함.
상품등록을 하고 굳이 저걸 다시 조회해줄 필요가 있나?
상품등록을 하고 등록내역조회로 갈텐데 그때 다시 등록한 상품 조회를 하지 않는가? 그때 id를 통해서 조회를 다시 하는 거니까
상품 등록 리스폰스에는 id만 보여줘도 될 것 같다.
상품 좋아요 에서도 누가 좋아요 했는지 유저 정보 리퀘스트 받아야하고,
좋아요 테이블에서도 유저 정보 받아야함.
별점도 마찬가지로 누가 좋아요 했는지 유저 정보 리퀘스트 받고,
별점 테이블에서도 유저 정보 받아야함.
주문생성에 product_human_limit 뭔지 제대로 못 쓸거면 지워라
주문 수정에도 누가 주문했는지 유저 정보 있어어 함.
만약 토큰을 사용한다면 리퀘스트 헤더에 들어갈텐데 그럼 유저정보 안들어가는게맞음.
암튼 인증인가를 토큰으로 할거면 안들어가도 되는데, 그럴거면 공통적으로 받는 리퀘스트 헤더라는 항목이 들어가면 더 좋을 것 같다.
토큰을 이용한다면 리퀘스트 헤더의 내용이 다 똑같을거라서 이 내용이 어딘가에 저장되면 좋을 것 같다.
주문 취소도 본인 식별값 하나 있어야함
상품과 마찬가지로 리뷰에서도 이미지 저장을할때, 멀티파트로 던지는 게 아니라 아니라,
이미지 이름으로 던지고, 그 이름을 사용해서 업로드하는거다.
이미지경로에는 엔터티에 기입되는 이미지이름, 또는 URL이 있을테니 멀티파트파일말고 url로 바꿔라
phonenumber가 아니라 phone_number로 바꿔라
상점은 셀러로 바꾸고
인기검색, 추천검색, 최근검색은 한개로 합쳐도 될것같다. 리소스 절약위해서.
스펙이 너무 크다
프로젝트 규모를 줄여보는 것도 좋을 것 같다.
누군가는 이미지저장
누군가는 로그인인증인가
누군가는 주문과 모든도메인논리를 포함하는그런걸 파보고
범위를 줄이고 뾰족하게 학습을 해보는 게 좋아보인다.
동시성 제어를 반드시 해야하는 영역인 것 같다.
구조상 주문을 했고, 주문을하면 재고데이터가 차감이 돼야하는데, 누가 동시에 주문요청을 해버리면
재고는 하나만 차감될 수도 있다.
동시성 제어 관련도 파보면서 학습해보는 거에 포함이 돼야 한다.
이대로는 굉장히 큰 작업 단위가 될 수 있을 것 같다.
이런식으로 긴 피드백을 받아서 갈아엎고 있는 중이다. 너무 많다...