Spring Boot JPA 연관관계 및 애그리거트 경계 설계: 연관관계 vs 키 값

들어가며

모임 플랫폼을 개발하면서 User 도메인의 연관관계 설계에 대해 깊이 고민하게 되었습니다. Users, UserCategories, UserFollow, UserRatings 엔티티 간의 관계를 어떻게 설정할지에 대한 여러 접근법을 공유합니다.

---

초기 요구사항 분석

사용자 도메인에서 관리해야 할 엔티티들은 다음과 같았습니다:

• Users: 기본 사용자 정보
• UserCategories: 사용자의 관심 카테고리
• UserFollow: 사용자 간 팔로우 관계
• UserRatings: 사용자에 대한 평가 (모임 후 상호 평가)

 

설계 과정의 여러 시행착오

1단계: ManyToOne 단방향 접근

처음에는 성능을 고려하여 ManyToOne 단방향 관계를 고려했습니다.

// UserCategories
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id")
private Users user;

// Users에는 연관관계 없음

장점:

• N+1 문제 없음
• 단순한 구조

문제점:

• 비즈니스 로직이 분산됨
• Repository가 여러 개 필요
• 트랜잭션 관리가 복잡함

 

2단계: 양방향 연관관계 고려

전통적인 JPA 패턴인 양방향 연관관계를 검토했습니다.

// Users
@OneToMany(mappedBy = "user", cascade = CascadeType.ALL)
private List<UserCategories> categories;

// UserCategories  
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id")
private Users user;

장점:

• 객체지향적
• 직관적인 탐색
• 일관성 보장

문제점:

• 양방향 동기화 복잡성
• LazyInitializationException 위험
• 성능 이슈 가능성

 

3단계: 최종 결론 - OneToMany 단방향

결국 OneToMany 단방향 관계를 선택했습니다.

---

핵심 설계 결정사항들

1. 애그리거트 경계 설정

모든 연관 엔티티들이 Users에 생명주기를 의존한다고 판단했습니다:

• UserCategories: 사용자 없이는 의미 없음
• UserFollow: 사용자 탈퇴 시 팔로우 관계도 삭제되어야 함
• UserRatings: 사용자에 대한 평가이므로 사용자와 함께 관리

 

2. 단방향 관계의 선택 이유

개발 편의성 vs 성능을 고민한 결과, 다음과 같은 이유로 단방향을 선택했습니다:

• 양방향 관계 동기화의 복잡성 회피
• 명확한 객체 그래프 방향성
• Users가 애그리거트 루트로서 모든 연관 데이터 제어

 

3. UserFollow의 특별한 처리

UserFollow의 경우 특별한 고민이 있었습니다. 팔로우 관계는 다음 두 가지 관점에서 조회가 필요합니다:

• 내가 팔로우하는 사람들
• 나를 팔로우하는 사람들

이를 해결하기 위해 UserFollow 엔티티에 양쪽 ID를 모두 포함했습니다:

Users에서는 내가 팔로우하는 사람들만 OneToMany로 관리하고, 나를 팔로우하는 사람들은 Repository 쿼리로 조회하도록 설계했습니다.

---

최종 엔티티 구조

User (애그리거트 루트)

 

UserCategory

UserRatings

---

설계의 장단점

장점

1. 명확한 애그리거트 경계: Users가 모든 연관 데이터의 생명주기를 관리
2. 트랜잭션 일관성: cascade 옵션으로 자동 관리
3. 단순한 Repository 구조: UsersRepository 중심의 관리
4. 객체지향적 접근: 자연스러운 객체 그래프 탐색

단점

1. 컬렉션 관리 복잡성: List 조작 시 주의 필요
2. 메모리 사용량: 연관 데이터까지 로딩 시 메모리 사용 증가
3. 부분적 Repository 사용: 일부 조회는 별도 Repository 필요

---

배운 점

1. 완벽한 설계는 없다: 모든 상황에 맞는 완벽한 설계는 존재하지 않으며, 프로젝트의 요구사항과 제약사항을 고려한 최적의 선택이 중요합니다.
2. 도메인 중심 사고: 기술적 구현보다는 도메인의 본질을 이해하고 이를 코드로 표현하는 것이 우선되어야 합니다.
3. 점진적 개선: 처음부터 완벽할 필요는 없으며, 요구사항 변화에 따라 점진적으로 개선해 나가는 것이 현실적입니다.

 

마무리

JPA 연관관계 설계는 정답이 없는 영역입니다. 프로젝트의 규모, 성능 요구사항, 팀의 역량 등을 종합적으로 고려하여 최적의 선택을 해야 합니다. 이번 경험을 통해 다양한 접근법의 장단점을 체험할 수 있었고, 향후 유사한 상황에서 더 나은 판단을 할 수 있는 기준을 마련할 수 있었습니다.