프로젝트 테이블 설계

# 1. 유저
- 유저 아이디 ( PK , 정수형 ID)
- 이메일
- 이름
- 비밀번호
- 역할 ( buyer || seller )

## 메모
1. 사용자는 구매자 또는 판매자가 될 수 있습니다.
2. 이메일을 로그인 아이디로 사용을 합니다.
3. 역할은 buyer가 디폴트값입니다.
4. 비밀번호 규칙
- 영문/숫자/특수문자 2가지 이상 조합 (8~20자)
- 아이디(이메일) 제외

---

# 2. 판매자
- 판매자 아이디 (PK, 정수형 ID)
- 유저 아이디 ( FK )
- 상점 이름
- 상점 이메일
- 상점 연락처

## 메모
1. 판매자 테이블은 역할이 판매자인 유저을 위한 판매자 정보를 담고 있는 추가 테이블입니다.
2. 유저와 판매자의 관계는 1 : 0..1 입니다. ( 한정된 기간안에 간단하게 가기 위함입니다. )

---

# 3. 상품
- 상품 아이디 (PK, 정수형 ID)
- 상품명
- 상품 설명
- 가격
- 재고
- 판매자 아이디 ( FK )

## 메모
1. 하나의 상품은 하나의 판매자에게 종속적인 개체입니다. 판매자가 없으면 상품의 존재가치가 사라진다고 오해할 수도 있지만 상품은 쇼핑몰 테이블 설계시 주요 도메인이라고 판단되어 강한개체로 판단하고 별도의 테이블을 만들었습니다.

2. 상품 테이블의 가격은 상품의 가장 최신 가격을 반영합니다.
---

# 4. 주문
- 주문 아이디 (PK 정수형 ID)
- 주문자 아이디 ( FK )
- 상품합계금액
- 배송비
- 총 결제 금액 ( 상품 총합계 금액 + 배송비 )
- 주문상태 ( 결제대기 || 결제완료 || 취소 )
- 수령인 이름
- 수령인 연락처
- 배송지 주소
- 배송지 상세주소
- 우편번호

## 메모
1. 유저와 주문간에 1:n관계로 정의했습니다. 데이터베이스 교과서상에서는 유저와 상품간 다대다 관계를 해소하기 위해 나온 테이블로 정의를 하고 있지만 좀 더 공부를 해보니 주문은 서비스에서 비즈니스 규칙 및 상태전이등을 가져야하는 핵심 도메인으로 여겨지고 있으므로 하나의 엔터티로 정의를 합니다.

2. 주문상태는 결제 상태와 연동되어 업데이트 됩니다.
3. 배송비는 코드 레벨에서 일괄 처리하겠습니다.
---

# 5. 주문상세
- 주문상세 아이디 ( PK 정수형 ID)
- 주문 아이디 ( FK )
- 상품 아이디 ( FK )
- 주문수량
- 주문당시 가격
- 소계가격 ( 주문수량 * 주문당시 가격 )

## 메모
1. 주문과 상품은 n:m 관계를 만듦니다. 따라서 주문상세 관계라는 테이블을 따로 정의를 합니다.
2. 가격은 변동될 수 있으므로 주문상세 테이블에 주문된 상품의 주문당시 가격을 저장합니다. ( 주문시의 스냅샷 )
3. 한 주문내에서 동일한 상품 중복을 방지합니다. (주문 아이디, 상품 아이디)로 유니크 키를 만듭니다.
---

# 6. 결제
- 결제 아이디 (PK 정수형 ID)
- 주문 아이디 ( FK )
- 유저 아이디 ( FK )
- 트랜잭션 id
- PG사 정보
- PG사 응답전문
- 결제방법 ( 카드 )
- 결제금액
- 결제상태 ( 결제성공 || 결제실패 || 결제대기 || 결제취소 )
- 결제요청시간
- 결제완료시간

## 메모
1. 토스 페이먼츠 API를 활용할 계획입니다.
2. 멱등성을 보장해야합니다.
3. 통화코드는 KRW로 고정합니다.
---

# 추가 고려사항
- 환불
- 배송