중간발표 준비
•
13일
◦
18,19일 중 하루를 선택
•
주말 간 중간발표 준비
성능개선 사항 및 인프라 결정
문제
•
성능 이슈와 개선사항에 알맞지 않은 인프라 구조
•
프로덕션 개선사항의 부족
•
현 상황
◦
Github Actions
▪
Github → S3
◦
Code Deploy
▪
S3 → EC2
해결방안
•
Fargate 사용 여부
문제
•
Fargate를 사용할 것인가
해결방안
•
추후 시스템이 커지면 적용하기로 결정
•
그렇게 필요한가,,,?? 라고도 느낌
Frontend
문제
•
어떤 것으로 구현할 것인가?
해결방안
•
React 적용예정!
◦
React, Vite, MUI 이용 예정
◦
기타 필요 라이브러리는 따로 페이지를 추가 예정.
•
재윤님이 담당해주시기로 함!
도메인, 스코프가 너무 좁지않나?
문제
•
도메인 스코프가 너무 좁다고 느낌
•
현 도메인에서는 입찰 도메인만 존재한다고 판단
해결방안
•
기본 요구사항을 오늘(2024.01.11(목)까지 완성시키고, 내일(2024.01.12(금)에 도메인을 확장하자
API명세서, 네이밍이 어색하지 않나?
문제
•
어떤 것은 상품 아이디이고, 어떤 것은 구매입찰 아이디라서 통일성이 떨어짐
◦
상품 구매 API의 경우는 POST:/api/buy/1 이고, 1은 productId 임
◦
구매 입찰 취소 API의 경우는 DELETE:/api/buy/1 이고, 1은 구매입찰id임
◦
이는 같은 1로 보이지만 다른 id를 나타내는 문제가 있었음.
해결방안
•
구매 및 판매 입찰 취소 API를 DELETE:/api/buy/{구매입찰id} 에서 DELETE:/api/buy/bid/{구매입찰id} 로 중간에 /bid 계층을 추가하기로 함
•
(이전)
◦
POST : /api/buy/1
◦
DELETE : /api/buy/1
◦
POST : /api/sell/1
◦
DELETE : /api/sell/1
•
(이후)
◦
POST : /api/buy/1
◦
DELETE : /api/buy/bid/1
◦
POST : /api/sell/1
◦
DELETE : /api/sell/bid/1
Service에서의 Facade Pattern??
문제
•
주문 서비스에서 여러 도메인을 사용하게 됨
◦
쿠폰
◦
구매자
◦
판매자
◦
입찰 상품
◦
,,,
•
어떤 방법을 사용할까?
◦
Facade Pattern을 사용하여 서로 각기 다른 서비스를 의존
◦
vs
◦
여러 도메인 Repo에 직접 접근
해결방안
•
Facade Pattern 사용
◦
관심사 분리
▪
서로 다른 도메인에서의 수행 역할을 분리하여, 행위의 내부 동작을 위임한다.
▪
내부 동작이 변경되어도, 이를 의존하는 서비스는 모른다.
◦
레포를 직접 가져다 썼을 때의 단점
▪
쿼리 이슈 발생 시, 역추적의 어려움
▪
도메인에 대한 동시성 제어 처리 메서드를 다른 도메인에서 작성하게됨
•
쿼리 수행 메서드
•
쿼리 수행 제한 처리 메서드
•
Facade Pattern 네이밍
◦
후보들
▪
1안 : 도메인1 + 도메인2 + Facade , 도메인 1, 2는 알파벳 순
▪
2안 : 도메인1 + 도메인2 하면 무엇을 하는 파사드인지 모르니, 기능 + Facade 하자.
•
이거로 채택!!
•
Facade 객체 저장 위치
◦
기존
▪
각 도메인 내의 facade 디렉토리에 존재.
◦
이후
▪
bc1.gream.common 디렉토리 추가
▪
bc1.gream.model 을 bc1.gream.common 내로 이동
▪
bc1.gream.common.facade 디렉토리 추가 후 여기에 작성
PR 규칙 하나 추가
문제
•
PR 분량이 너무 많아서 리뷰 시간이 오래 걸려서 오히려 묵혀지는 문제 + 그래서 main과 변화가 커짐
해결방안
•
1커밋 1파일변화 여도 좋으니 PR 분량은 최대한 적게 유지하기…
◦
리뷰어가 이정도는 먹기 좋은 크기라고 생각할 정도로 적게 유지하기….
유저 프로필 조회 시 가져올 데이터들
문제
•
유저 프로필에는 다음과 같은 데이터가 필요하고, 이에 대한 세부 데이터가 필요하다.
◦
닉네임, 로그인id, 구매 내역, 판매 내역, 관심 상품, 쿠폰 내역
◦
닉네임과 로그인id는 user 엔티티에서 바로 가져올 수 있으나, 나머지는 가져올 데이터 필요.
해결방안
•
아래 4가지를 API로 따로 만들기로 함.
•
구매 내역 및 판매 내역에서,
◦
입찰 중과 종료 2가지 상태만 남겨두기.
◦
입찰 중이든 종료 든 모두 상품 이미지로 표시하고,
◦
구매 완료 시 카드 클릭하면 기프티콘 이미지를 모달창 띄우기
[1. 구매 내역]
•
주문 리스트 중, 유저 id랑 주문의 구매자 id랑 같은 주문 리스트.
•
가져와야 할 필드 : 구매가격, 브랜드, 상품이름, 기프티콘 이미지, 입찰여부
•
/api/buy/history/onprogress : 입찰 중인 구매 내역
•
/api/buy/history/end : 구매 완료한 구매 내역
[2. 판매 내역]
•
주문 리스트 중, 유저id랑 주문의 판매자 id랑 같은 주문 리스트.
•
가져와야 할 필드 : 최종거래가, 브랜드, 상품이름, 입찰여부/api/buy/history/onprogress : 입찰 중인 구매 내역
•
/api/sell/history/onprogress : 입찰 중인 판매 내역
•
/api/sell/history/end : 판매 완료한 판매 내역
•
/api/buy/history/end : 구매 완료한 구매 내역
[3. 관심상품 내역]
•
관심 상품으로 상품을 가져온 리스트
•
가져올 필드 : 브랜드, 상품이름, 상품이미지, 즉시 구매가
•
/api/products/like : 관심 상품 내역
[4. 쿠폰 내역]
•
쿠폰 테이블에서 가져온 리스트
•
쿠폰 이름, 할인 형태, 할인, 쿠폰 상태
•
/api/coupons : 쿠폰 내역