refactor: 스타카토 양방향 연관관계 끊기

[linirini]

🤮 As Is

리팩터링하고자 하는 파트와 이유를 구체적으로 설명해주세요.

이전에 CascadeType을 PERSIST로 변경하면서 자식 삭제를 수동으로 하도록 리팩터링 했습니다. 그 과정에서 스타카토 수정 시 삭제된 이미지를 수동 삭제하는 작업을 놓쳤습니다.
급한대로 CascadeType을 ALL로 수정했습니다. 해당 작업을 다른 삭제 작업처럼 수동 삭제하는 방식으로 리팩터링이 필요하다고 판단했습니다.

CascadeType.PERSIST 를 활용하여 부모 엔티티(Moment)에서 자식 엔티티(MomentImage)의 생성주기를 관리하게끔 구성하고,
update, delete 시에 이미지 삭제는 수동으로 서비스에서 MomentImageRepository에 직접 쿼리를 날리는 형식으로 구성될 것 같습니다.

---

2024/12/11

+) 삭제 작업을 JPA에게 위임하지 않고, 수동으로 삭제를 구성하는 과정에서 전이속성 CascadeType.PERSIST만이 남게 되었고,
CascadeType.PERSIST 또한 불필요한 쿼리(이미지당 Insert 쿼리 하나씩)가 발생한다는 것을 인지하였습니다.

• 기존에 Image 5장을 저장할 때 디비에 나가는 쿼리가 5개였는데, insert 쿼리 또한 1개의 BulkInsert로 구성될 수 있습니다.

따라서 CascadeType.PERSIST 를 삭제하여, 생성 또한 서비스 로직내에서 관리하게 된다면 양방향 연관관계를 끊을 수 있겠다는 생각이 들었습니다.

• 양방향 연관관계를 끊게 된다면 양방향으로 발생할 수 있는 여러 문제들이 자동으로 해소된다는 장점이 존재합니다.

그렇다면 양방향 연관관계를 끊는 것이 장점만 존재하는가?

• 꼭 그렇지만은 않다고 생각합니다.
  생각해볼 수 있는 단점 중 가장 먼저 생각난 것은 서비스 로직이 복잡해진다는 것입니다.
  • -> 해당 부분은 퍼사드 패턴을 도입하는 이유가 될 수도 있겠습니다.
• 휴먼에러가 일어날 가능성이 높습니다.
  • MomentImage는 최대 5개로 구성되어야 하며, 해당 비즈니스로직을 검증하는 부분을 기존에는 Moment를 생성할 때 이루어졌습니다. 이로 인해 서비스 로직에서 MomentImages 일급컬렉션을 이용해야 합니다.

🤩 To Be

리팩터링 방향을 구체적으로 공유해주세요.

우선은 전에 회의에서 다루었던 내용과 같이 양방향 연관관계를 끊는 형식으로 구성할 예정입니다.
기존에 Moment가 가지고 있던 MomentImages는 필드상에서 제거되어 Embedded 타입으로 사용되지 않을 것 같습니다.

• Moment에서 MomentImages 삭제
• MomentService에서 Moment 생성 시 MomentImages 일급컬렉션을 이용해서 비즈니스로직 검증 후 저장
• insert가 BulkInsert가 될 수 있게끔 MomentRepository 에서 커스텀 Query 작성 필요
• update 시 기존에 존재하는 모든 이미지 삭제 후 다시 모든 이미지 생성

😇 이때까지 끝낼게요!

리팩터링 완료 예상 날짜를 작성해주세요. 신중하게 생각해요!

• 12/13

😵 참고 자료(선택)

🙇‍♀️이슈 확인했어요:)

팀원에게 이슈 확인을 부탁해요!

• @Ho-Tea
• @BurningFalls
• @linirini

[BurningFalls]

@linirini
확인했습니다. 혹시 급한대로 CascadeType을 ALL로 수정했습니다. 이걸 반영한 시점이 언제인가요?

[linirini]

@linirini 확인했습니다. 혹시 급한대로 CascadeType을 ALL로 수정했습니다. 이걸 반영한 시점이 언제인가요?

반영 pr 링크 남깁니다!

[Ho-Tea]

@linirini @BurningFalls
Issue 한번 확인해주시면 감사하겠습니다.
새롭게 건의한 부분은 Moment와 MomentImage 양방향 연관관계를 끊는 것입니다.