[BE] 엔티티 간 꼭 객체참조를 해야하나?(by 레오)

[yenawee]

• Coupon의 경우 다양한 엔티티를 의존하면서 테스트 시 더미데이터 작성에 매우 어려움을 겪었습니다.
• 예를 들어, Coupon을 조회할 때 Cafe를 사용할 일이 없는데 Cafe를 객체 참조함으로써 Cafe더미데이터가 필요했습니다. 이를 단순히 CafeId로 참조하는 방식도 있다고 하더라구요. https://www.youtube.com/watch?v=dJ5C4qRqAgA&t=2289s
• 다만 id로 참조할 경우 페치조인을 먹일 수 있는지는 더 알아봐야 할 것 같아요. 같이 쓸 일이 없어서 id참조를 하는데 페치조인 가능 여부가 중요한지는 또 모르겠네요.
  • 이 관점에서 생각해보면, fetch join을 사용할 일이 없는 객체는 id참조로 변경하는 것도 괜찮을지도?
• Coupon과 CafeCouponPolicy의 경우 Coupon을 조회하면서 CafeCouponPolicy가 필요할 때고 있기 때문에 fetch join을 위해 객체 참조를하고, Coupon과 Cafe의 경우 fetch join이 필요 없다는 것은 함께 사용하는 일이 없는 것이기 때문에 cafeId만 참조하게 하는 방식..?

[yenawee]

관련 내용을 숙지하고
다음 논의 때 추가 진행하자고 결정

[gitchannn]

레오 덕분에 완전 유익한 영상을 잘 봤슴당.


보고 나서 우리 패키지 의존성을 쭉 보면서 직접 그려봤슴다.

저 명강의에서 언급했던 것 중에 인상깊었던게,

• 레이어드 아키텍쳐로 패키지를 나누는게 일단은 의존성을 관리하기에 가장 편리하다.
• 의존성이 조금 어색하거나, 꼬여 있는 곳은 3가지 방법으로 의존성을 풀어내는 방법에 대해서 소개하죠.
• 풀어내다보면, 어느새 레이어드 아키텍쳐보다 도메인을 앞에 놓고 의존성을 풀어내는 단계가 마지막에 나옵니다.

우리도 현재 레이어드 아키텍쳐로는 완전하게 하고 있는데,
entity 내부에서 불필요한 의존성이 존재한다고 저도 생각함니다.
우리가 처음 entity를 설계하는 날에는 의존성을 정말 참조로 박아놔야 하는지에 대한 고민은 거의 하지 않고,
테이블에서 참조하는 경우에 거의 무조건적으로 객체도 참조를 하도록 넣어놨어요.

이 상태가 현재 강의에서 말하고 있는, 객체 참조로 어디로든 갈 수 있는게 장점인데 큰 단점인 상태인 것 같아요
같이 말해보면 아주아주 재밌을 것 같습니다!

[yenawee]

변경점이 너무 커질 것 같고 코드도 안정화된 상태라 서비스가 더더욱 안정화된다음에 다시 얘기해봅시다