WebSite(wiselyshave) Clone Project - Part1.시작&데이터모델링

안녕하세요. 이 포스트는 시리즈로 구성되어있습니다.

<1차 Clone Project 회고>
WebSite(wiselyshave) Clone Project - Part1.시작&데이터모델링
WebSite(wiselyshave) Clone Project - Part.2 Data Modeling & End Point Refactoring
WebSite(wiselyshave) Clone Project - Part.3 views.py Refactorin
WebSite(wiselyshave) Clone Project - Part.4 후기

이번 포스트에서는 실제 웹사이트를 클론하는 프로젝트를 시리즈를 작성하고자 합니다. 클론하는 사이트 대상은 와이즐리 면도기(https://www.wiselyshave.com/) 사이트 입니다.

TMI지만, 와이즐리 제품을 사용해보신 분들은 가성비도 괜찮고 면도도 잘 된다고 하네요.

1. 시작하며

팀은 프론트엔드 개발자 3명, 백엔드 개발자 2명으로 구성되었습니다. 저는 백엔드로 상품목록, 장바구니(결재) API 구현을 맡았습니다. 순서를 크게 보면, 데이터 모델링 - 크롤링 - API 구현으로 구성되어 있습니다. 물론 애자일 개발방식을 지향하기 때문에 하나씩 구현하기로 했습니다.

시작하기 전에 생각했을 때는 심플하고 깔끔해서 보기 좋다는 생각이었는데, 실제로 보니 크롤링할 데이터가 풍부하지 않은게 약간 아쉬웠습니다. 그래도 장바구니나 모델링 구조가 특이하게 나온다는 점이 마음에 들었습니다.

프론트엔드 관점에서 보면 쉽지 않은 클론 사이트입니다. 상태관리 할 요소도 많이 있고, 애니메이션이 약간 화려한데 그 부분은 제외할 수 있기 때문입니다. 로그인 할 때도 아이디를 먼저 체크해서 이름의 일부를 보여주는 처음 보는 방식을 적용했습니다.

2. 데이터 모델링

주문할 수 있는 대분류의 제품이 5개인데 구매방식이 4가지가 있습니다. 색상 고르는 상품, 사이즈 고르는 상품, 대용량으로 구매할 수 있는 상품, 피부타입을 골라야 선택되는 상품으로요. 구현하는 입장에서는 복잡하게 느껴집니다.

이 방식에 맞춰 데이터 모델링의 구현이 필요합니다. 실제 사이트에서 색상과 제품은 ManyToMany(다대다) 관계이고, 사이즈와 제품도 ManyToMany(다대다) 입니다.(물론 와이즐리 제품은 그렇진 않지만, 최대한 정석대로 하고자 했습니다.) 그리고 아무것도 선택할게 없는 면도날은 단일 품목으로 끝입니다.

이렇게 복잡한 상품구성 때문에 어쩔 수 없이 맞춰준 부분이 있습니다.(하단에서 설명)

그리고 이번 프로젝트의 꽃인 장바구니(주문) 관련 테이블이 있습니다. 관련 테이블 구성은 어느정도 통용되는 모델이 있었습니다. 약간 복잡해진 부분은 상품이 크게 세 종류가 있기 때문에(윗 문단에 볼드체로 표기) 조금 더 복잡해졌습니다.

우선 작성한 모델링을 올려보겠습니다.

 

 

전부를 설명하기에 너무 길어지기에 주요한 테이블만 설명하도록 하겠습니다. 테이블의 색은 각 APP을 구분하기 위함입니다.
(파란색: UserApp, 분홍색: ProductApp, 초록색: OrderApp

2.1 User App

상대적으로 가장 익숙하고 심플했습니다. 물론 Order App과의 연결된 포인트가 있긴 하지만요.
아래에 주요 포인트를 -로 설명하겠습니다.

- genders라는별도의 테이블로 성별을 id 값으로 저장

- 배송지(shippings) 테이블이 존재, User와 배송지는 ManyToOne의 관계입니다. 한 유저가 여러 배송지를 가질 수 있으므로

- 배송지에 is_default 값을 넣어줘 주 배송지를 구분

- 가입시 체크박스로 가입경로를 확인하는데 이 테이블이 User와 ManyToMany 관계 입니다. 따라서 결과를 저장하는 중간테이블을 생성

2.2 Product App

사실상 첫 주차에 가장 고민을 많이하게 만든 부분입니다. 크게 세 번을 수정할 정도로 많은 고민을 했습니다.

- 대분류를 하는 제품(Products) 테이블이 존재 선물세트, 면도기세트, 면도날, 쉐이빙 젤, 애프터쉐이브가 있습니다.

- 이 각각의 제품은 두 개의 ManyToMany 관계(color, size)와 한 개의 무속성(면도날) 제품이 있습니다.

- 저는 이를 제품(products)과 상품(products_sizes,products_colors,blade_products)으로 구분하였습니다.

- 상품은 제품을 참조하는 관계입니다.

- 애프터쉐이브 제품은 피부타입(skin_type)을 선택하는 것이 있어서 코드 테이블을 별도 분리 했습니다.

2.3 Order App

마지막으로 장바구니-주문 관련 App 입니다. product App에 비해 고민은 덜 했지만 실제 관련 API 구현은 훨씬 더 복잡할 것입니다. 

- 대표적으로 orders 테이블이 있습니다. 이 테이블은 유저가 장바구니에 담기 시작할 때 부터 하나의 id를 갖고 객체 생성이 됩니다. 하나의 배송정보를 참조하는 shipping_id가 있고, 주문상태를 담는 order_status_id가 있습니다.

- order_status가 어떻게 보면 이 테이블의 핵심적인 역할이라고 할 수 있습니다. 각 상태별로 장바구니, 주문, 배송중, 배송완료 등을 나타냅니다. 즉, order가 어떤 상태인지에 따라 완전히 다른 로직을 태우는 것입니다.

- 마찬가지로 중요한 테이블 중 하나로 order_items가 있습니다. 이 테이블은 user와 상품(products_sizes,products_colors,blade_products)의 ManyToMany 관계에 있는 테이블 입니다.
중요한 정보로 수량(quantity)가 있고 각 상품의 id 컬럼이 있습니다.

- ERD 구조도 우측에 있는 order_images 테이블이 있습니다. 이 테이블은 장바구니나 주문 됐을 때 상품의 이미지를 보여주는 테이블 입니다. 각 상품의 아이디를 참조 합니다.

- 마지막으로 구매완료 시, 주문한 각 상품별로 review를 적을 수 있는 reviews 테이블이 있습니다.