[퍼온 글] 연관관계 편의 메서드에 대하여

참고 링크: https://www.inflearn.com/questions/16308

 

먼저 연관관계 편의 메서드를 정의하면 다음과 같습니다.

(사실 이 연관관계 편의 메서드라는 이름은 제가 만들었습니다. ㅎㅎ)

연관관계 편의 메서드: 양방향 연관관계를 한번에 설정하는 편리한 메서드

질문이 엔티티 A와 B가 서로 양방향 연관관계인데, 어디에 연관관계 편의 메서드를 두는게 좋은가?로 이해했습니다.

우선 3가지 선택지가 있습니다.

- 엔티티 A에 둔다.

- 엔티티 B에 둔다.

- 엔티티 A,B에 둘다 둔다.

둘다 두는 것은 혼란을 가중하기 때문에 제외하고, A, B중 하나를 선택해서 사용하는 것이 좋다 생각합니다. 그러면 여기서 A,B 중에 하나를 선택해야 하는데 사실 이 부분이 고민하셨던 것 처럼 정답이 없습니다. 이 부분은 JPA의 영역이라기 보다는 오히려 객체지향 설계의 영역이기 때문입니다.

예를 들어서 Order와 Delivery 중에서 우리팀의 핵심 비즈니스가 주문이라면 Order에 연관관계 편의 메서드를 두는 것이 더 나은 선택일 확율이 높습니다. 그런데 만약 우리팀이 배달을 책임지는 팀이고 Order엔티티는 있지만, 관련된 정보는 크게 의미가 없다면 Delivery를 중심으로 비즈니스 로직이 진행되므로, Delivery가 중심 엔티티가 되기 때문에 Delivery에 연관관계 편의 메서드를 두는 것이 나은 선택이 됩니다.

도메인 주도 설계(DDD)에 나오는 Aggregate Root라는 개념을 사용한다면, Aggregate Root에 연관관계 편의 메서드를 두는 것이 좋은 선택일 확율이 높습니다.

조언들 드리자면, 실제 엔티티를 사용하는 비즈니스 로직을 구현을 하실 때, A에 연관관계 편의 메서드를 두고 개발을 해보고, 바꾸어서 B에 연관관계 편의 메서드를 두어 보면, 어디에 두는 것이 더 유지보수 하기 쉬운지 바로 보이실 꺼에요. 이게 뭔가 엔티티 만으로는 잘 안보이고, 실제 비즈니스 로직과 함께 있을 때는 어디에 두는 것이 좋은지 바로 보이더라구요. (서비스 계층에서 코드가 몇줄 줄어들고, 쉽게 이해되고 등등) 생각해보니 저도 엔티티를 설계할 때는 A라고 했다고, 중간에 실제 비즈니스 로직을 보고 B로 리펙토링 한 경우도 있었습니다^^

참고로 연관관계 편의 메서드에 대해서는 책 190p 5.6.2 연관관계 편의 메소드 부분에 짧게 설명이 되어 있습니다.

추가로 올해 안으로 준비중인 강의는 두가지 입니다^^

두 강의로 처음 목표했던 JPA 관련 강의는 마무리가 됩니다^^

- 실전 스프링 데이터 JPA

- 실전 QueryDSL

감사합니다.