1.회의 안건

• ERD 상세 설계
• API 상세 설계 (excel sheet 이용)
• 동시성 이슈 발생 가능한 부분 이야기 해보기
• TTD 기반 API 설계 방법 의논하기
• Log Gathering

2.회의 내용

Entitiy 설계

• 필드값이 자주 변하는 부분을 따로 테이블 구현 (제품의 수량, 셀러의 수익, 유저의 소지금)

• user 엔티티

  • user - user _wallet의 관계에서 User_Wallet 이 User 의 pk 값을 필드값으로 가지는 비식별관계로 ERD를 구성하기로 하였음
  • 추후의 user 탈퇴 기능의 서비스 확장성 고려하여 user의 데이터를 완전히 삭제하는 방식이 아닌 Soft Delete 방식으로 update 쿼리를 날려서 deleted 값을 변경해주는 방법으로 구현하도록 이야기가 나옴
  • 유저의 소지금은 주문과 동시에 차감되도록 로직을 구현하도록 함

• seller 엔티티

  • user와 동일하게 seller_wallet 엔티티 별도 구성
  • 셀러의 income은 뷰에서 주문확인을 한후 주문 변경 API를 호출하여 배송완료로 상태값을 변경후 income을 증가시키는 로직으로 구현하기로 함

• orders 엔티티

  • total_price, 상품이 어쩔수 없이 삭제되어 product에 대한 정보가 없을때 대비하여 미리 계산하여 필드값에 넣어준다 → 캐쉬, 스냅샷
  • 배송완료 되는 시점 : 뷰 구현 부분에서 셀러가 주문 확인 버튼을 누르면 제품과 주문 상태값을 바꾸는 API 실행되게 변경한다.
  • orders 엔티티에 seller_id를 별도 단일 필드로 추가하는 방안 고려 (반영 안한 상태)

• product 엔티티

  • ProductStatus : 판매중 → 재고 있음, 일시 품절 → 수량 0, 품절 → 상품 삭제 시(soft delete)
  • product 의 수량은 user가 상품 주문 할때 차감

• review 엔티티

  • orders - reviews : one to one(or zero)
  • 리뷰와 user, product와의 연관관계를 추가하는 방안 고려 (반영 안한 상태)
  • order 필드의 order Status 배송완료 시점에 리뷰 작성
  • 같은 제품에 대한 중복 주문 시, 중복 리뷰 작성 가능