동일한 API, 서로 다른 쿼리스트링에 따른 서비스 호출에 대하여
문제
아래와 같이 API 를 설계하면, 동일한 컨트롤러에서 서로 다른 쿼리스트링에 따른 서로 다른 서비스를 호출해야함
해결방안
•
아래와 같이 변경하기로 함!
기획 변경으로 인한 API 명세서 수정(주문관련)
문제
•
기획과 ERD가 틀어지면서 API명세서도 변경되어야 할 것 같음
•
구매 입찰 시 쿠폰을 등록할 수 없게 하였음(API 명세서에서는 쿠폰 등록 가능)
◦
구매 입찰 시에 쿠폰을 등록하고 싶다면, 즉시 판매 요청이 들어와 주문으로 넘어갔을 때 등록할 수 있다.
•
기프티콘 등록 API를 새로 만들어야 하는가?
•
쿠폰 등록 / 조회 / 삭제 API를 새로 만들어야 한다.
해결방안
•
구매 입찰 시에도 쿠폰을 등록할 수 있게 변경(포인트제이기 때문에 가능)
•
기프티콘 등록 API를 만들기로 함
•
본인 쿠폰 조회 / 삭제 API 만들기로 함
◦
쿠폰 데이터는 DB에서 관리자가 저장하기로 함
쿠폰 테이블 및 구매 단계에서 어느 부분에 적용해줄지
문제
•
구매입찰이 주문완료되어, 결제로 넘어갈 때, 쿠폰 적용을 어떻게 할 것인가?
◦
Op.1 : 구매입찰과 쿠폰 사이에 구매입찰쿠폰테이블을 만들기
◦
Op.2 : 주문처리할 때 쿠폰을 선택하여 처리
▪
비즈니스 로직이 복잡해짐
•
쿠폰 처리 단계, 어떤 프로세스로 접근할 것인가?
◦
주문처리 시, 쿠폰 선택하는 처리단계를 하나 더 추가해야 함
◦
쿠폰 선택에 따라 최종가격 연산 처리 단계를 추가해야함
해결방안
•
입찰을 넣을 때 쿠폰을 선택하고, 입찰할 때 바로 포인트 차감하도록 함.
•
구매 입찰에 Long 쿠폰id를 넣어주고, 쿠폰 테이블에는 쿠폰 사용 여부(사용가능 / 사용중 / 사용불가)를 입력해 주는 방향으로 해결
•
주문 테이블에서는 구매가와 최종 거래가만 남기기로 함.
AWS 권한 설정
문제
•
EC2에 권한이 없어서 S3랑 CodeDeploy를 사용하지 못했다.
해결방안
•
현재 즉시거래하는 기능이 구매 / 판매에 있는데 올바른가?
문제
즉시 구매 / 즉시 판매를 주문 도메인에서 만드는게 나을지 여부
해결방안
•
구매 도메인과 판매 도메인을 주문 도메인으로 합침
