[WIL] 부트캠프 4주차

 

한 일

• 주문/결제과정에서 여러 작업(재고차감, 포인트 사용)의 원자성 보장 : 트랜잭션을 이용
• 동시성 처리 : 좋아요 수 증감, 재고 차감, 포인트 사용에 대해 하나의 자원에 여러 요청이 몰렸을 때 정합성을 보장하기 위한 처리. DB를 이용하여 적절한 lock 사용하기
• 쿠폰 설계 : 정액/정률이라는 여러 정책을 개방/폐쇄 원칙에 맞게 설계하고 주문 단계에 적용하기 

 

공부해야 할 것  

• Springframework의 Transaction에 대해 알아보기 
  
  

해야 할 일 

• 이번주 프로젝트를 하면서 고민했던 부분이 Facade 계층에 코드가 너무 많아 지는 것이였는데 application 계층 내에 유효성 검증을 위한 별도  Resolver 를 두도록 코드 리팩토링 
  • resolver를 사용하는 부분 코드 리뷰 요청드리기 : 리졸버가 덩어리째로 가져가는 건지. 아니면 주문의 각 단계별로 하나씩 떼어지는 것인지를 모르겠다. 해당 부분 정리해서 질문하기 
• 좋아요 수 등록 부분, 트랜잭션 관련 피드백 받은 부분 적용하기 
• 쿠폰 정책관련 코드 enum에 둔 것 인터페이스+구현으로 변경

 

facade내 검증 처리 리팩토링 방향

facade 내 검증 로직이 있어서 어떻게 분리해야 할까 고민이었는데 아래 두 방식을 피드백 받았다.

1. 도메인 레이어에 도메인 서비스나 얇은 컴포넌트를 두거나
2. facade 내에 별도 resolver를 두어 처리하는 방법

facade에서 처리하는 검증은 사용자에게 받은 ID들이 실제 존재하는지 판별해야 하므로 DB 조회가 필요한 부분이다. 
해당 부분을 application layer에서 처리하는 2번 방식으로, facade 내 별도 resolver에서 처리하려고 한다.
왜냐하면 API에서 전달받은 ID의 존재 유무 같은 입력 검증은 애플리케이션 레이어에서 먼저 끝내고, 그 다음에 도메인 레이어에서 비즈니스 유효성을 확인하는 것이 맞다고 판단하기 때문이다.