[문제해결] 클래스 연관관계 설계 중 의견 차이

회원과 상품 찜 두 클래스 간의 연관관계를 어떻게 가져가는게 좋을까?

시나리오

1. 회원은 상품 여러개를 찜 할 수 있다.

2. 한 상품은 여러 회원에게 찜 당할 수 있다.

3. 회원을 탈퇴하면 해당 회원의 찜 역시 삭제되어야한다.

4. 상품이 삭제되면 관련된 찜들이 삭제되어야한다.

5. 회원은 상품을 찜하고 찜을 취소할 수 있다.

6. 회원은 자신이 찜한 목록을 조회할 수 있다.

 

발생한 문제 사안

상품 찜과 회원간의 관계를 양방향으로 할지, 단방향으로 할지 또한 단방향일 경우 어떤 방향으로 가져갈지

 

초기 설계는 다음과 같았다.

양방향을 모두 갖는 형태

해당 설계에서의 문제점은

지극히 객체지향적인 관점에서 설계가 되었다는 점이다.

 

우리는 좀 더 RDB의 관점에서의 설계도 필요하다고 판단되었다.

 

상품에서 상품 찜에 대한 접근이 없으므로 상품찜 -> 상품 , 단방향으로 설정

 

하지만 진짜 문제는 상품찜과 회원관의 관계였다.

의견 1) 상품찜과 회원 양방향 관계

1. LazyFetch 가 적용되기 때문에, 상품 찜을 불러온다한들, User를 직접 활용하지 않으면 무거워지지 않을것이다.

2. Cascade.remove 옵션으로 자동 삭제가 가능하다.

3. 양방향 관계의 주인만 잘 설정해주면 양항뱡 관계의 이슈는 해결된다고 생각된다. (조회만 하는 경우)

 

 

의견 2) 상품찜 -> 회원 단방향 관계

1. 회원에서 상품찜에 대한 정보를 갖게되고, 회원과 다른 클래스와의 연관관계도 이런식으로 갖게된다면 

회원이라는 클래스 본연의 정보보다 많아질 수도 있음

2. 회원 본연의 기능(회원정보 조회, 삭제 등) 에서 벗어난 (회원의 찜 목록 조회) 기능이 계속해서 추가되면

회원 Service 의 역할이 모호해짐

 

의견 3) 회원 -> 상품찜 단방향 관계

1. 문맥상 보면, 회원이 상품찜을 관리하는 것이지 상품찜이 회원을 관리하는 것이 아니다.

2. 상품찜에서는 회원을 조회하는 일이 없지만, 회원에서는 "내 찜 목록 조회" 가 있으므로 주인을 회원으로 갖는게 문맥상 일치

3. 회원에서 상품찜을 Collection 을 통해 직접 관리 할 수있으므로 삭제나 수정에 용이

 

 

여러 이야기를 통해 처음에는 의견 1로 결정을 내렸다. 

이유는

클래스 관계를 다시 봤을때

상품 찜은 상품과도 관계를 갖고있고, 회원과도 관계를 갖고있다.

이때 양쪽 모두 양방향인경우 cascade 를 통해 삭제를 진행하면 동기화의 문제가 발생할 것이다.

따라서 상품과는 단방향, 회원과는 양방향이면서 cascade를 갖도록 설계를 해봤다.

 

하지만 우리는 이 문제에서 간과한 부분이 존재했다.

Cascade

그러나 cascade의 자동화는 우리에게 개발적 편리함을 주지만,

운영 유지보수에는 최악이라는 판단을 하게되었다.

 

cascade는 N+1 문제를 야기시킨다.

 

따라서 cascade를 제거하고 별도의 쿼리를 생성하여 일괄적으로 삭제하는 로직을 갖는 방식을 갖기로 하였고,

의견2 에 맞춰 설계를 다시 진행했다.

 

 

결론

우리는 이번 의견 토론을 통해 중요한 사실 2개를 배워갔다.

 

1. 초기 설계는 되도록이면 양방향을 지양하고, 단방향을 지향하자!

  우리는 객체지향 언어인 java 를 통해 개발을 하고있지만, 

  객체지향은 잠시 내려두고 RDB의 관점에서의 설계를 신경쓸 필요가있다.

  계속해서 양방향 관계를 만들면서 설계와 구현을 한다면,

  어디서 어떤 잘못된 쿼리가 나갈지 예측하기 어렵고,

  잘못된 쿼리를 발견했을때도 어떤 관계에서 문제가 발생했는지 찾기가 어려울 수 있다.

  또한 서로를 참조하면서 로직을 구성하게 된다면 유지보수의 어려움이 생길 수도 있다.

  (service로직에서의 SRP 를 벗어날 수도..?)

 

  어쩌면 객체지향이라는 핑계로 성능을 포기하고 있는지 한번 돌아볼 필요가 있는것 같다.

 

2. cascade는 그냥 사용하지 말자!

   너무 단정지어 이야기하기는 힘들지만,

   필자는 앞으로 작은 토이프로젝트가 아닌 이상 cascade는 사용하지 않을 생각이다.

   이유는 자동 이라는 말이 오히려 더 큰 문제를 야기할 수 있다는 점이다.

   편함에 현혹될 수 있겠지만, 귀찮더라도 수동적인 로직이 

   후에 유지보수시 발생하는 문제들에 대해 더 체계적으로 해결할 수 있다고 생각되고,

   문제 발생 자체를 방지하는 기점이 될 수 있기 때문이다.

   

   https://daehwan2yo.notion.site/CASCADE-a324465c93284c0caf2ea9a64c0ee08e

CASCADE 는 언제나 옳은 것일까?

 

 

 

"daehwan2yo"   contact

software, soongsil univ  <  now

udsward@gmail.com  < email

https://github.com/daehwan2yo<    git

daehwan2yo - Overview