오늘 진행한 일

리뷰를 작성하면 해당하는 장비가 작성자 인벤토리에 추가되는 기능 구현

우리 서비스의 비즈니스 규칙으로 리뷰를 작성하면 그 리뷰의 대상인 장비가 작성자의 인벤토리에 자동으로 추가된다.를 정했다. 여기서 나와 블링의 의견이 갈렸는데, 나는 서비스 규칙으로는 리뷰를 작성하면 장비가 인벤토리에 추가되어야 하지만, API 설계적인 측면에서는 요청 한 번에 하나의 일만 해야 하는거 아닐까? 리뷰 작성에 대해 OK 응답을 받으면 그 때 인벤토리에 아이템을 추가하는 요청을 또 보내는 것이 맞지 않을까? 라는 입장이었고, 블링은 리뷰 작성과 인벤토리 추가를 같이 묶기로 결정한 이상 API로도 하나로 보는 것이 맞을 것 같다. 만약 분리해서 리뷰 작성은 성공하고 인벤토리 추가 요청을 보내기 전에 모종의 이유로 연결이 끊겨버린다면 그건 클라이언트 입장에서 요청에 대한 원하는 결과를 얻지 못하는 것이 아닌가? 라는 의견이었다. 여기서 고려해볼 부분이 트랜잭션이었는데, 한 요청에서 전부 처리하려면 리뷰 작성과 인벤토리 장비 추가를 같은 트랜잭션 내에서 관리해야 하기 때문에 리뷰 작성에서는 문제가 없어도 인벤토리 장비 추가가 실패하면 리뷰도 다시 롤백된다. 나는 이게 어색하다고 생각했는데 블링의 리뷰 작성 -> 인벤토리에 추가를 하나의 기능이라고 본다면 오히려 리뷰만 작성되고 인벤토리에 추가가 안되는 쪽이 더 이상하다. 인벤토리에 추가하는 과정에서 문제가 발생한다면 롤백시키고 사용자에게 그 사실을 알려주는 쪽이 더 나을 것 같다. 라는 의견에 설득당했다.

사실 덕분에 컨트롤러 단의 코드를 변경시킬 필요 없이 리뷰에 관련된 서비스 로직만 수정해서 해결할 수 있었다.

@Transactional
public Long saveReviewAndInventoryProduct(final Long productId, final Long memberId,
                                          final ReviewRequest reviewRequest) {
    final Member member = memberRepository.findById(memberId)
            .orElseThrow(MemberNotFoundException::new);
    final Keyboard keyboard = keyboardRepository.findById(productId)
            .orElseThrow(KeyboardNotFoundException::new);
    final Long reviewId = saveReview(reviewRequest, member, keyboard);
    saveInventoryProduct(memberId, keyboard);
    return reviewId;
}

private Long saveReview(final ReviewRequest reviewRequest, final Member member, final Keyboard keyboard) {
    final Review review = reviewRequest.toReview(keyboard, member);
    return reviewRepository.save(review)
            .getId();
}

private void saveInventoryProduct(final Long memberId, final Keyboard keyboard) {
    final InventoryProduct inventoryProduct = InventoryProduct.builder()
            .memberId(memberId)
            .keyboard(keyboard)
            .build();
    inventoryProductRepository.save(inventoryProduct);
}

오늘 발생한 이슈

위에서 설명한 서비스 규칙에 대해 API를 둘로 나눌 것인지 아니면 하나의 API로 모두 처리할 것인지에 대한 논의 외에는 크게 이슈 사항이 없었다.

내일 목표

팀 규칙으로 데모데이 전 목요일에는 데모데이 준비로 인해 배포에 영향을 끼칠 수 있는 어떠한 커밋도 하지 않기로 결정했다. 그래서 아키텍처 구조나 패키지 분리에 대해서 개인적으로 공부하는 시간과, 스프린트 3에서 진행할 내용들에 대해 팀원들과 미리 논의하는 시간을 가지려 한다.