할인율과 할인가 계산처리 시, 예외케이스 처리
문제
•
할인 계산처리 시, 예외케이스를 어떻게 해야할까?
◦
할인율이 퍼센터지를 넘어가거나
◦
고정할인가가 지불가격보다 큰 경우
해결방안
•
위 두 가지 케이스에 대해 예외처리를 하기로 함!
도메인에 따른 레이어를 어떻게 나눌까 ?
문제
•
현재 Service라는 이름으로 서로 다른 역할을 처리하고 있음
1.
Data에 대한 CRUD
2.
유스케이스 따른 흐름제어 << 다른 도메인 서비스 의존
•
아래와 같은 흐름으로 로직을 처리하고 있음
◦
컨트롤러 → 다른 도메인에 의존하여 흐름처리를 하는 유스케이스 → Data 에 대한 데이터 조회 / 가공
그렇다면 우리는 어떻게 레이어를 나눌 수 있을까?
해결방안
•
아래와 같은 아키텍쳐로 분리하기로 함
◦
Provider
▪
다른 도메인 서비스를 주입
▪
유스케이스 제어
◦
Service
▪
Repository에 접근하여 데이터 조회 / 데이터 가공
남은 요구사항에 대한 컨트롤러와 Provider ?
문제
•
아래와 같은 요구사항들이 남았음
•
쿠폰과 포인트에 대한 도메인을 어떻게 나누어야 할까?
•
남은 API에 대해서 Controller 와 Provider들을 어떻게 규명지을까?
해결방안
•
도메인을 아래와 같이 분리
•
API 당 Controller가 1:1이면 Overhead가 너무 큼
◦
도메인에 따른 비슷한 역할의 처리를 하나의 Controller로 묶자
◦
Controller를 나누는 기준은 Query 와 Command로!
▪
GET → Query
▪
POST,PATCH,PUT,DELETE → Command
•
Buy 와 BuyBid 네이밍이 너무 헷갈림
◦
현재 Buy 자체가 BuyBid 를 함축적으로 사용하고 있으므로 Buy로 통일
•
Controller와 Provider는 아래와 같이 규명하기로 함 !
포인트 증감 시나리오 ?
문제
•
포인트 증감 시나리오가 어떻게 될까??
해결방안
•
아래와 같은 로직으로 처리하기로 함
호스트와 도메인의 주인이 다를 때 연결하는 방법
문제
•
서버를 여는 AWS 계정과 도메인의 주인이 다를 경우 접속이 어려운 점이 있었음
해결방안
쿠폰 상태에 따른 쿠폰 사용 가능 / 불가능 기능 상실
문제
•
쿠폰의 상태에 따른 쿠폰을 사용 가능한지 불가능한지 여부를 알 수 있어야 하는데 현재 그 기능이 존재하지 않음
해결방안
•
1월 16일 리팩토링을 거쳐 새로 기능을 구축하기로 함
시세 차트 표기 시, 일일 시세 계산 방법
문제
•
상품 상세 페이지의 시세 차트를 표기 시, 하루 동안의 여러 체결 거래가 있음에도 단일가로 표기를 하고 있어서, 우리 서비스 에서도 표기법을 정해야 했음
해결방안
•
하루동안의 평균 가격을 일일 시세로 표기하기로 함.
