TIL - 작고 귀여운 이커머스 프로젝트 ER-D

solee·2022년 3월 2일
0

TIL

목록 보기
6/20

과일을 판매하는 e-커머스 웹서비스를 만들어 보게 되었다. 1차적으로 일단 머리를 싸매고 고민해서 작성한 다이어그램인데, 나중에 보면 분명 이게 뭔지 싶을 것이므로 내 기준 세세히 설명해 본다.

모델링을 생성할 앱을 기준으로 설명해 본다.


users

users app에는 회원에 대한 정보를 주로 다룰 것이다.

  • users

이메일로 아이디 대신 사용할 것이다. 또 아마 내가 코드를 짠다면 비밀번호 찾기를 이메일 인증을 통해 활용하고 싶다. 이메일 전송이 조금 까다로울 것 같지만 생각만 해 본다면 모듈을 따로 생성해서 진행하면 될 것 같고 꽤 재미있을 것 같다.

또 시간적, 인력적인 한계로 결제 모듈을 적용하기 어려워 예치금만을 사용해 결제하기로 해 deposit과 적립금 point 컬럼을 생성했다.


  • shopping_carts

한 회원이 여러 상품을 장바구니에 담을 수 있으므로 일대다 관계를 가진다.

장바구니는 products app이나 orders app에 넣을지에 대해서도 고민했는데, 회원 한 명이 가지는 장바구니라는 성격이 강하다고 생각했고 또 장바구니에서 언제든 상품을 삭제하거나 수정할 수 있고, 장바구니에 담았다고 반드시 구매하는 것도 아니므로 users app에 추가하게 되었다.
quantity를 잊고 있었는데 동기들 덕분에 뒤늦게 추가할 수 있었다. wishlist같은 경우 여기서 quantity가 빠질 뿐 기능적으로는 같아서 구현할 필요는 없어 보인다.

또 장바구니에 중요한 부분이 있는데, 바로 비로그인 장바구니다. 비로그인한 사람이 장바구니를 사용할 수 있는 사이트도 있고 없는 사이트도 있기 때문에 더 고민이 됐는데, 프론트 3 백 3이서 2주간 진행하는 프로젝트라 이것까지는 구현하기 힘들 것이라 판단돼 비로그인 장바구니는 제외하기로 했다. 자바 프로젝트를 진행했을 때에는 세션이나 쿠키에 담는 방향으로 개발했었는데, 이번에는 프론트 분들이 진행하는 거라 어떻게 하는지는 모르겠다.




products

products app에는 상품에 관한 정보가 담긴다.

  • products

과일이기 때문에 created_at 대신 receiving_date를 사용했는데, 입고일을 뜻한다. 그러나 찾아보니 과일의 경우 정해진 유통기한이 없어 다른 판매사이트들에서도 유통기한을 표기하는 대신 최대한 빨리 섭취하기를 권고하고 있어서 단순한 입고일 외에 쓰임이 있을지는 아직 모르겠다. 여력이 된다면 입고일 기준 2주가 지나면 기한임박 태그를 띄운다거나 하는 식으로 응용하고 싶다.


  • product_images

products 테이블에서는 썸네일 이미지만 담고, 나머지 세부 이미지들은 여기에 들어간다. 일대다 형태로 한 상품이 여러 이미지를 가질 수 있다.


  • categories

카테고리는 너무 많으면 페이징을 위해 필요한 데이터의 용량이 너무.... 너무 많아지기 때문에 카테고리는 작게 4가지 정도로 줄였다. 국산과일 / 수입과일 / 냉동과일 / 세트상품 이다. 원래는 제철과일을 넣고 싶었지만 이것도 마찬가지로 admin 페이지가 있어 관리해줄 수 있는 게 아니라면 제하는 게 나을 것 같아 회의 끝에 수정되었다. 태그 기능을 추가로 개발할 수 있다면 그때에는 제철과일을 넣었으면 좋겠다.




orders

말 그대로 주문에 관련된 데이터를 다룬다. 이를 products app에 추가할지에 대해 논의했는데 어디에 들어가기 애매하기도 하고 세부적으로 나누는 것도 좋을 것 같아 나누기로 결정했다.

  • orders

시작하기 전에 고민이 조금 있었다. 한번 주문할 때에 물건이 여러 개 들어갈 수 있는데 전체 정보를 전부 가지고 상품 하나하나를 표현하는 것은 데이터가 너무 중복되고, 갱신 이상이나 삭제 이상 등 문제가 생길 여지가 많아 정규화하기로 결정했다. 그래서 주문내역 자체에서는 총 금액과 배송비, 사용한 적립금과 예치금 정도만 확인할 수 있도록 하고 상품 하나하나에 대한 세부사항은 아래 order_details에서 표현하도록 하였다.

또 주소록을 고민했는데, 이 경우 주소를 끌어오는 것은 물론 한 회원이 여러 주소를 저장할 수 있으므로 새로운 테이블이 필요해진다. 추후 추가될 수도 있지만 크게 중요하지 않기도 하고 프론트에서 할 일이 너무 많아져 제하고 회원정보에서 주소를 가져오도록 했다.


  • order_details

구매 내역 하나에 대한 각 상품별 정보를 담는다. 수량과 구매로 얻을 수 있는 적립금 등을 가지고 있다. product_price가 있는데 이것은 할인이 들어간 경우 금액을 저장하기 위해 일부러 추가한 컬럼이다. 멘토님께 듣기로는 이런 경우 log를 사용해 해당 기간의 구매내역에 영향을 미친 할인을 따로 가져올 수 있다고 하는데, 우리는 간단하게 구매 당시의 금액만 저장하기로 했다.



image_url로 필드명을 변경하거나 price 관련 필드들을 decimal 필드로 변경하는 등의 수정사항들이 있었지만 큰 줄기에서 변한 부분은 없다.
나중에 글로벌 서비스를 개발해보고 싶다...

profile
DA DA DA

0개의 댓글