/////
Search
Duplicate

24년 1월 11일 목요일

날짜
2024/01/11
중간발표 준비
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를 나타내는 문제가 있었음.

해결방안

구매 및 판매 입찰 취소 APIDELETE:/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.modelbc1.gream.common 내로 이동
bc1.gream.common.facade 디렉토리 추가 후 여기에 작성

PR 규칙 하나 추가

문제

PR 분량이 너무 많아서 리뷰 시간이 오래 걸려서 오히려 묵혀지는 문제 + 그래서 main과 변화가 커짐

해결방안

1커밋 1파일변화 여도 좋으니 PR 분량은 최대한 적게 유지하기…
리뷰어가 이정도는 먹기 좋은 크기라고 생각할 정도로 적게 유지하기….

유저 프로필 조회 시 가져올 데이터들

문제

유저 프로필에는 다음과 같은 데이터가 필요하고, 이에 대한 세부 데이터가 필요하다.
닉네임, 로그인id, 구매 내역, 판매 내역, 관심 상품, 쿠폰 내역
닉네임로그인iduser 엔티티에서 바로 가져올 수 있으나, 나머지는 가져올 데이터 필요.

해결방안

아래 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 : 쿠폰 내역