CQRS
이슈
•
CQRS 분리를 어디까지 해야할까?
◦
컨트롤러까지?
◦
서비스까지?
해결방안
•
CQS 일단 서비스에만 붙이기로결정
•
주문 도메인 이외에는 CQRS 적용 안 하기.
즉시구매/구매입찰과 결제상태
이슈
•
구매 입찰 / 즉시 구매 모두 상품 선택 & 카드 결제 & 쿠폰 로직처리를 한 번에?
◦
입찰시 결제대기상태에 걸릴수 있음 → 문제
◦
방법 1 → 컬럼추가 (결제대기 → 구매,판매완료) =>거래종료여부(거래구분)
◦
방법 2 → 테이블 분리(구매,판매)
◦
방법 3 → 컬럼에 enum으로 구분? (구매,판매입찰 → 결제대기 → 구매,판매완료)
•
join을 어차피쓸꺼면 주문 테이블 클 필요 있나..?
•
쿠폰 사용 지금은 붙이는게 맞나?
해결방안
•
결제를 미리 등록하게끔 하자!
◦
구매 입찰 시 결제를 미리 등록
▪
본인 계좌 등록
•
이에 따라 계좌 등록 처리 또한 처리해주어야 한다
◦
계좌 등록 API 처리
▪
사용자 등록
▪
프로필 수정
▪
계좌 등록 API를 따로 분리
◦
계좌 테이블로 처리한다
▪
(FK) 사용자 id값
▪
계좌번호
▪
,,
•
포인트로 결제할 수 있게끔 처리한다.
•
포인트 충전은 결제시스템을 통해 처리한다.
◦
추후 구현 예정
•
즉시구매와 즉시판매를 아래와 같이 처리하기로 함
◦
(이전) 즉시구매와 즉시판매를 각각 구매입찰,판매입찰로서 처리
▪
구매입찰,판매입찰을 생성
▪
이에 대한 주문데이터도 생성
◦
(이후) 즉시구매/즉시판매 시, 주문건으로 처리
주문처리가 완료된 입찰데이터는 어떻게 구분할까???
•
구매 입찰 처리를 아래와 같이 하자
◦
마감시간이 현재시간보다 이전이면 종료된 입찰
◦
구매입찰 완료 시, 마감일자를 입찰시간으로 변경
◦
주문처리가된 입찰데이터는 삭제한다.
•
판매 입찰 처리를 아래와 같이 하자
◦
마감시간이 현재시간보다 이전이면 종료된 입찰
◦
판매입찰 완료 시 마감일자를 입찰시간으로 변경
◦
주문처리가된 입찰데이터는 삭제한다.
•
마감기간을 static 변수로서 저장(현재는 7일), 이후 변경할 수 있게함
•
주문과 쿠폰을 분리
◦
유저와 쿠폰만 연관관계를 지정
•
도메인 특성상, 주문취소랑 환불은 불가능하다.
◦
기프티콘이므로 사용여부를 판별할 수 없으므로 주문취소와 환불은 불가능하다.
AWS - RDS & S3
이슈
•
RDS로 바로 할지 ec2로컬로 붙일지
•
s3 생성 해야함
해결방안
RDS로 하기로함 (완)
S3 생성 (완)
•
EC2의 장점
◦
가볍다
◦
비용측면 효율
◦
이렇게 로컬로 구현하다가 RDS로 넘기자
•
RDS
◦
어차피 RDS로 넘겨야한다
Code Convention
이슈
•
Repository 선언을 어떻게 해줄까
◦
JpaRepository 확장
import org.springframework.data.jpa.repository.JpaRepository;
public interface PostsRepository extends JpaRepository<Posts, Long> {
}
Java
복사
▪
실무에서는 실용적인 관점에서 사용함.
◦
vs
◦
RepositoryDefinition 구현
@RepositoryDefinition(domainClass = Post.class, idClass = Long.class)
public interface PostsRepository {
}
Java
복사
▪
위와 방식과 다르게, JpaRepository 의 기본 제공 메서드를 테스트 코드로 작성할 수 있음.
해결방안
•
좀 더 편하게 쓸 수 있게 아래로 통일
•
JPA에서 기본적인 기능들을 제공함, 컬럼에 따른 파인튜닝이 아닌 조인을 해와서 튜닝할 필요 없어서 편하게 JPA 상속받아 사용하자. 신경 쓸 부분을 간소화 하자.
•
위의 방식을 사용하기로 함.
•
이미 잘 만들어진 도구를 가져다 쓰는 것과, 개발자 간 서로 다른 구현 메서드가 아닌, 표준화된 메서드로 공통의 관점에서 사용 가능.
import org.springframework.data.jpa.repository.JpaRepository;
public interface PostsRepository extends JpaRepository<Posts, Long> {
}
Java
복사
Service의 인터페이스 분리?
이슈
•
Service의 인터페이스가 필요한가
해결방안
•
구현체만 만들다가 인터페이스가 필요해지는 시점에 그 객체만 분리
◦
시스템 간 연계가 있다면 인터페이스를 사용하지만, 내부에서 사용한다면 클래스만 만들어서 사용함
◦
그리고 버전업을 해야하는 상황이라면 (-ImplV1, -ImplV2) V1, V2 다 필요한 상황이기 때문에 인터페이스도 하나 더 만들어서 사용함.
•
1:1로 가져가는 상황에서 이점이 없는 것 같다. 관습적인 것 같다. 강의에서 그런 것 같다.
◦
Impl을 가져가면 이점이 있다.
•
확장성을 고려해서 구현체를 갈아끼울 수 있다.
◦
ex) mysql 저장할건지 vs redis에 저장할건지
•
갈아 끼울만한 건 인터페이스로 만들고, 추상화할 필요 없다면 구현체만 만들것.
