리뷰 작성 로직에서 서비스 의존성과 엔티티 의존성

[Kim0914]

현재 리뷰를 생성하기 위해서는 크게 ReviewService, StoreService, PhotoService가 필요합니다.

구조는 아래 사진과 같습니다.
ReviewService는 StoreService와 PhotoService를 의존하고 있는 상태입니다.

반면에 도메인(엔티티)는 Photo가 Review에 의존하고 있는 상태입니다.

즉, Photo는 Review 없이 생성할 수 없는 객체이므로 상위 서비스인 ReviewService에서 Review를 주입시켜야 하는 상황입니다.

서비스와 도메인 간의 의존성이 반대로 되어 있습니다.

그러므로 Photo는 PhotoService에서 생성하지 못하고 ReviewService에서 생성하고 있습니다.

# ReviewService

private void saveImagesIfExists(List<MultipartFile> images, Store store, Review review) {
        if (images == null) {
            return;
        }
        List<String> imagePaths = photoUtils.upload(images, store.getStoreName());
        List<Photo> photos = imagePaths.stream()
                .map(imagePath -> Photo.builder()
                        .review(review)
                        .path(imagePath)
                        .build())
                .toList();
        photoService.save(photos);
    }

# PhotoService

@Transactional
public void save(List<Photo> photos) {
    for (Photo photo : photos) {
        photoRepository.save(photo);
    }
}

이를 해결할 수 있는 방안이 몇 개 떠올라요

1. 양방향 매핑
   Review와 Photo를 양방향으로 걸어놓은 다음 Review에 연관관계 편의 메서드를 추가한다.
   다만 이 방법은 구조적으로 명확히 해결하는 방안은 아니라고 생각합니다.

2. 테이블 분리
   Photo 테이블에서 Review 테이블을 분리합니다.
   중간 테이블로 ReviewPhoto 테이블을 가져야할 것 같은데, 도메인 관점에서는 분리 하는게 적절할까? 고민해볼 필요가 있을 것 같아요 !

같은 레이어의 도메인끼리 양방향 의존성을 가지는 것은 아니기 때문에, 동작에 당장 문제가 있지는 않지만...!
개선해야할 부분이라고 생각합니다 ~~

[woo-chang]

우선 정말 좋은 고민을 해주신 것 같아 저도 배워갈 수 있는 시간이 될 것 같네요 👍

말씀해주신 것처럼 서비스 의존성 방향과 도메인 의존성 방향이 다르기에 문제가 되는 상황이라고 생각해요. 해결 방법도 다양하게 생각하신 점 좋습니다!
제시해주신 2가지 방법에 대해 저도 고민해 보았습니다.

양방향 매핑

public class Review {

    ...

    public void addPhotos(List<String> filePaths) {
        for (String filePath : filePaths) {
            Photo photo = Photo.builder()
                            .review(this)
                            .path(filePath)
                            .build();
            this.photos.add(photo);
        }
    }
}

연관관계 편의 메서드는 다음과 같이 작성될 것이라고 생각해 봤어요. 하지만 해당 방법도 photoRepository를 사용하지 않지만 결국 photoRepository를 사용하는 것처럼 reviewService에서 Photo 도메인에 대한 저장 로직이 수행되는 것으로 이해했어요. 방안에도 적혀있듯 구조적으로 명확히 해결하는 방안이 아니라는 것에 저도 동의합니다 🥲

테이블 분리
결국 Photo에서 Review에 대한 의존성을 끊어내야만 해결할 수 있는 문제인 것 같아요! 그러면 아래와 같은 순서로 로직이 진행될 것 같아요.

리뷰 작성 API 호출 시

1. 가게 서비스에서 가게 저장 및 조회 로직을 수행한다.
2. 사진 서비스에서 사진을 업로드하고 DB에 사진 저장 로직을 수행한다.
3. 리뷰 서비스에서는 가게 서비스와 사진 서비스로부터 만들어진 도메인을 바탕으로 리뷰를 작성한다.
4. 이때 리뷰와 사진 사이에는 중간 테이블이 존재하기에 이를 엮어주는 것은 리뷰 서비스의 책임이라고 볼 수 있다.

---

따라서 저는 테이블을 분리하는 것이 적절한 해결방안이라고 생각이 들어요 :)

추가적으로 도메인 관점에서 분리하는게 적절할까라고 적어주셨는데 적절하지 않을 것 같다고 판단한 근거가 궁금해요 🤓

[Kim0914]

테이블을 분리하는 방법이 제일 적절해 보이네요 !

도메인 관점에서 분리하는게 적절할까라고 말했던 이유는, 순수한 도메인 관점으로 설계한다면 Review가 photos를 가지도록 설계할 것 같아서요 !
Player가 자신의 Cards를 가지고 있는 느낌? 처럼요.

왜냐하면 리뷰 객체 입장에서는 자신의 사진을 알고 있는 것이 굉장히 자연스럽기 때문이죠. (순수히 제 생각입니다 ㅎㅎ)

우창씨가 말씀해주신 것처럼, 양방향 연관관계 매핑을 도입한다고 해서 구조적으로 해결되는 문제는 아니라고 생각했습니다 ~

결론적으로ReviewPhoto 엔티티 즉, 중간 테이블을 생성해 관리하도록 변경하겠습니다 😄