JPA/DDD 관점에서의 직접 참조/간접 참조

🤔 문제 상황

JPA를 사용하며 객체를 설계할 때, 직접 참조와 간접 참조 각각 어느때에 사용하면 적절할지에 대한 고민이 생겼다.
더불어 회사에서 코드 리뷰를 하다가 간접 참조로 설계를 한 팀원의 코드에 왜 여기서 간접 참조를 했나요? or 왜 여기는 직접 참조를 했나요? 등의 리뷰를 보고 나도 아무 생각없이 객체간 설계를 하고 있던 것은 아닌가 하는 생각이 들었다.

🕊️ 나의 생각

우선 각 용어의 뜻을 보자면

• 직접 참조 : 말 그대로 Entity간의 참조를 직접적으로 하는 것이다. 구체적인 방법으로는 JPA 사용시 @OneToOne / @ManyToOne등의 어노테이션을 써서 매핑(참조)를 하는 것을 말한다.
• 간접 참조 : 직접 참조의 반대의 의미로, 외래키(FK)를 맺지 않고 다른 Entity의 (더 나아가서는 다른 루트 애그리거트) 식별자(PK)를 참조하는 방식이다.
  • 여기서 애그리거트란 관련 도메인을 하나의 군집으로 묶은 것을 말한다.

위 두가지 용어가 실제로 가장 많이 나오는 부분이 DDD(도메인 주도 개발) 관점에서의 개발을 할 때이다.
루트 엔티티는 애그리거트의 대표 엔티티이다. 애그리거트에 속한 엔티티는 루트 엔티티에 직/간접적으로 속한다.

하지만 개념적으로만 생각하면 도메인의 설계에 큰 문제가 없을 것 같지만 실제 코드로 개발을 하다보면 그 기준이 모호해지는 순간이 오게된다.

🧐 직접 참조와 간접 참조의 선택 기준

내가 경험해보고 느낀 점을 통해 전반적인 선택 방법을 소개하자면

1. 애그리거트 경계

• 직접 참조: 같은 애그리거트 내부의 엔티티들 간에는 직접 참조를 사용한다. 이는 애그리거트의 일관성과 응집도를 높이는 데 도움이 된다고 느꼈다.
  • 같은 애그리거트내의 엔티티들은 주로 생명 주기가 비슷하거나 조회에 함께 사용되는 경우가 많다.
• 간접 참조: 서로 다른 애그리거트에 속한 엔티티들 간에는 간접 참조를 사용한다. 이는 애그리거트 간의 결합도를 낮추고 독립성을 유지하는 데 도움이 된다.
  • 다른 애그리거트내의 엔티티들은 생명 주기가 다르고, 조회시에는 참고할 수 있는 식별자(PK)정도만 있어도 충분하다.

2. 성능 고려사항

• 직접 참조: 자주 함께 조회되는 엔티티들 간에는 직접 참조를 사용하면 성능상 이점이 있을 수 있다. JPA의 지연 로딩(lazy loading)을 활용하여 성능을 극대화 시킬 수 있다.
• 간접 참조: 대규모 데이터를 다루거나, 특정 엔티티가 자주 변경되는 경우에는 간접 참조가 유리할 수 있다. 불필요한 데이터 로딩을 방지하고 시스템의 확장성을 높일 수 있다.

3. 비즈니스 규칙과 도메인 모델

• 직접 참조: 비즈니스 규칙상 강한 연관 관계가 있는 엔티티들 사이에서는 직접 참조가 도메인 모델을 더 명확하게 표현할 수 있다.
• 간접 참조: 느슨한 연관 관계나 선택적인 관계를 표현할 때는 간접 참조가 적합할 수 있다.

🗺️ 실제 적용 사례

🪡 직접 참조 사례

@Entity
public class Order {
    @Id
    @GeneratedValue
    private Long id;

    @ManyToOne
    private Customer customer;

    // ... 기타 필드와 메서드
}

이 경우, Order와 Customer 사이에 강한 연관 관계가 있고, 주문을 조회할 때 대부분 고객 정보도 함께 필요하다고 판단되어 직접 참조를 사용했다.

🪄 간접 참조 사례

@Entity
public class Review {
    @Id
    @GeneratedValue
    private Long id;

    private Long productId;  // Product의 ID만 참조

    // ... 기타 필드와 메서드
}

이 예에서는 Review와 Product가 서로 다른 애그리거트에 속한다고 가정했다. 리뷰는 제품의 전체 정보가 아닌 식별자ID만 알면 충분하므로 간접 참조를 사용했다.

🎯 결론

직접 참조와 간접 참조의 선택은 단순히 기술적인 결정이 아니라 도메인 모델의 설계와 밀접한 관련이 있다.
각 방식의 장단점을 이해하고, 프로젝트의 요구사항과 도메인 특성에 맞게 적절히 선택하는 것이 중요하다고 생각한다.

• 같은 애그리거트 내부: 직접 참조 선호
• 다른 애그리거트 간: 간접 참조 선호
• 성능과 확장성: 상황에 따라 적절히 선택
• 도메인 모델의 명확성: 비즈니스 규칙을 잘 표현할 수 있는 방식 선택

결국, 객체 간의 관계를 설계할 때 "왜 이렇게 설계했는지"에 대한 명확한 이유를 가지고 있어야 한다. 이는 주도적이고 의식적인 개발과 더 나아가 전체 시스템의 견고성과 유지보수성을 높이는 데 기여할 것이라고 생각한다!