1. 사용자는 Every-Cheap 서비스에 회원가입을 할 수 있다.

   1. 회원가입을 할 때 username, phoneNumber, password를 입력 받는다.
      1. username 은 영소문자 4 - 10 글자 형식이다.
         1. username은 중복이 불가능 하다.
      2. phoneNumber은 010 - 9999 - 9999 형식으로 이뤄져야 한다.
      3. password 는 영소문자, 대문자, 특수문자, 숫자를 포함한 8 - 15 자리 형식

2. 사용자는 Naver /Google /kakao / 로컬 로그인 을 통해 서비스에 가입할 수 있다.

   1. 소셜 로그인을 통해 가입한 사람은 구매 혹은 입찰 시도 시 본인 인증 절차를 한 번만 거친다.
      1. 이미 인증된 사용자라면 본인 인증은 패스한다.
   2. 로컬 로그인을 통해 가입한 사람은 구매 혹은 입찰 시도 시 본인 인증 절차를 한 번만 거친다.
      1. 로컬 로그인시 username, password를 입력 받는다.
         1. 로그인시 회원가입과 마찬가지로 형식의 검증을 한다.
   3. 사용자는 프로필을 수정할 수 있다.
      1. password 를 수정할 수 있다.

3. 본인 인증된 사용자는 상품을 구매 할 수 있다.

   1. 상품은 관리자만 등록할 수 있다. 관리자는 서비스 개발자로 제한한다.
   2. 상품 구매 시 쿠폰을 적용할 수 있다.
      1. 쿠폰은 퍼센트 할인 과 금액 할인 으로 나뉜다.
      2. 쿠폰은 발급 된다. → 선착순 이벤트와 같은 요소를 고려해서 대용량 트래픽 필요
      3. 경매에는 적용할 수 없다.
      4. 하나의 상품에는 하나의 쿠폰만 적용할 수 있다.
   3. 상품은 단일로만 구매할 수 있다. (대신, 같은 상품을 여러 개 구매할 수 있다.)
   4. 상품의 재고보다 많은 수는 구매 할 수 없다.
   5. 재고가 하나인 상품을 동시에 구매할 경우, 결제를 먼저 완료한 사람에게 구매 기회가 주어진다.

4. 관리자는 경매를 등록하고, 오픈할 수 있다.

   1. 경매는 상품의 이름을 경매 이름으로 표기한다.
   2. 경매는 경매 이름 몇분으로 설정할지, 시작 가격, 상품 이미지, 경매 시작 시간으로 등록할 수 있다.
      1. 현재 가격은 경매가 등록될 때 시작 가격으로 정의한다.
      2. 시작 시간 + 경매 시간이 현재 시간 대비 지났으면 경매는 종료된다.
         1. 경매가 종료되면 최고 입찰자는 해당 상품에 대해서 결제 여부를 선택할 수 있다.

5. 사용자는 상품을 입찰 할 수 있다.

   1. 입찰을 해당 현재 경매의 현재 가격보다 적은 금액으로 입찰 할 수 없다.
   2. 입찰 받고 상품을 구매하지 않으면, black 횟수가 1회 누적되며, 3회 누적될 경우 블랙 리스트에 등록되고, 다시는 가입할 수 없다. (전화번호로 확인)
   3. 가장 높은 가격으로 입찰 한 사람이 구매하지 않으면, 그 다음으로 높은 가격으로 입찰한 사람에게 구매 기회가 주어지며, 이 과정은 세번째 입찰자에게 까지만 넘어가고, 세번째 입찰자도 구매하지 않는다면 유찰된다.

6. 결제 시스템은 구축 보류 중 (api 유료 이슈)

쿠폰 발급

• 쿠폰 일련번호를 각각 다르게 100개를 준다 > 사용자에게 쿠폰 지급하는 개념 → 사실 여기서 사용자가 쿠폰 리스트를 가져야 하지 않나 싶습니다
• 쿠폰 일련번호를 똑같이 주되, 개수 컬럼을 추가해서 100개인 것을 확인하는 방식입니다! >> 복합키를 주는거랑 같은방식 쿠폰 일련번호를 각각 다르게 하면, db 부하가 너무 커질 수 있을 것 같아서 걱정됩니다!! 제가 지금 마이크를 못 켜는 상황이라 죄송해요.
• 넵! 넵 어떤 말씀이신지 잘 이해가 안 됐읍니다.
• 쿠폰 이름이 같아도 일련번호가 다를 수 있는거죠!
  • 그래서 일련번호가 다르면, entity는 사실상 달라지는 걸로 이해했습니다.
  • 그러면 사용자는 여러개의 쿠폰 entity를 가질 수 있으니, 일대다 관계로 이해했습니다.
  • 사실 다대다 나오는게 좋지 않다고 해요!
  • 답을 찾으려고 노력해봤고, 두 가지의 선택지가 나왔고 한 가지를 선택했는데 여러 상황이 우려가 된다면 튜터님께 한 번 여쭤보고 속시원한 답을 얻는 것도 좋을 것 같습니다.

음 일단 저희가 선착순으로 쿠폰 발급하는 로직을 생각하고 있었는데요,

만약에 만 장의 쿠폰을 발급한다고 생각했을 때, 이건 종류가 하나라서 괜찮지만

여러개의 종류의 쿠폰을 다량 생산해야 한다고 생각했을 때, db에 들어있는 값이 너무 커지지 않을까 하는 마음과

어떤 쿠폰이 써졌는지 확인하기 위해

db를 조회하는 측면에서 저렇게 데이터가 많아지면 어떡하지? 라는 걱정에서 db 부하를 걱정했던 것 같습니다.