Aggregate 하위에 꼬리를 무는 Entity 는?

Question

헥사고날 아키텍처를 구현하면 먼저 Domain 부분을 구현하는것으로 아는데요,

A class, B class, C class가 있다고 한다면.

A class 에는 B의 List를, B에서는 C의 List를 가지고 있다고 합시다.

그러면 이런 상황에서는 A를 조회하게 되면 B를 여러개 가져오는것을 막기위해 JPA에서는 LazyLoading을 사용할텐데

문제는 Domain 개발 단계에서 JPA를 사용하지 않고 하는 경우에는 어떻게 개발을 하는지 궁금합니다. 즉, 하나의 Aggregate 를 중심으로 Entity가 계층적으로 줄줄이 이어진 경우가 있는지, 그렇다면 이를 어떻게 해결하는지 말입니다. Aggregate 하나 조회하면 저~기 최하위 계층 데이터까지 다 가져오는게 좀 이상한거 같아서요.

무조건 JPA를 사용한다고 생각하면 좋으나, 이를 나중에 다른 ORM으로 변경을 해도 문제가 없게 하는게 헥사고널의 취지라고 생각하다보니 이런 질문을 드립니다.

han jeong heon · Answer

안녕하세요 강의자 한정헌입니다.

domain을 구현할때 이런 중첩 계층화된 모델은 도메인 모델에서 바람직한 구조는 아닌 것 같네요.

즉 도메인 모델의 한 단위가 되는 어그리게이트를 모델링 할때, 여러개의 중첩적인 엔티티를 최대한 가지지 않게 설계해야 합니다.(어그리게이트 에는 개인적으로 한개 정도의 엔티티 설계가 적정하다 생각합니다.)

그런 구조를 피하기 위해 다음과 같이 진행합니다.

1. Aggregate Root 기준으로 설계

DDD에서는 한 Aggregate Root(Aggregate의 최상위 엔티티)에서 다른 Aggregate Root를 직접 참조하지 않도록 권장합니다.
즉, A -> B -> C 형태가 아니라 A가 B의 ID만 갖고, B가 C의 ID만 가지도록 설계하는 것이 일반적입니다.

2. Lazy Loading을 도메인 레이어에서 직접 구현

JPA의 Lazy Loading을 사용하지 않는다면, 직접 데이터를 가져오는 방식으로 구현할 수 있습니다.
예를 들어, A에서 B를 가져올 때, B의 리스트를 로딩하는 것이 아니라 BRepository를 통해 필요할 때 조회하도록 만들 수 있습니다.

class A {
    private List<Long> bIds; // ID만 저장
    
    public List<B> getBs(BRepository bRepository) {
        return bRepository.findAllByIds(bIds);
    }
}

이렇게 하면 A가 B를 직접 포함하지 않고 ID만 저장하여 필요할 때만 데이터를 가져올 수 있습니다.

답변이 되었기를 바라며, 감사합니다.

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. seonjun Moon님께서 궁금해하신 주제는 Hexagonal Architecture 및 Aggregate 디자인 패턴과 관련된 내용으로 보입니다.

Aggregate 설계는 데이터 일관성을 유지하고, 한 번에 하나의 Aggregate만 변경할 수 있게끔 하는 것이 중요한 목표입니다. Entity가 계층적으로 나열되는 경우 샘플 구조 예를 들어 드리면, 최상위 엔티티(A)는 집계(배열) 내에서 각각의 하위 엔티티(B, C)를 포함할 수 있는 구조가 될 수 있으며, 이러한 구조는 실제 데이터를 불러올 때 Lazy Loading과 같은 로딩 전략을 활용해 경제적이고 효율적인 데이터 조회를 가능하게 합니다.

하지만 질문하신 대로 JPA 등을 사용하지 않는 상황, 즉 ORM 독립적인 상황에서도 Hexagonal의 원칙을 유지하려면 기본적으로 다음과 같은 방법을 고려할 수 있습니다:

도메인 계층에서의 구조화: 도메인 모델 내에서 각 엔티티의 역할을 명확히 정의하고, 단일 책임 원칙을 유지하도록 설계합니다. 데이터가 계층 간에 어떻게 전달되고 조작될지를 명확히 정의합니다.
레포지토리 패턴 사용: 데이터 저장소에 대한 추상화를 지원하므로, 실제 데이터 접근 방법(JPA, 다른 ORM 등)과 도메인 로직을 분리합니다.
데이터 페치 전략 조정: 비즈니스 로직의 허용 범위 내에서 가장 많이 다뤄야 하는 데이터를 우선하여 필요에 따라 데이터 로딩을 조절합니다.

이와 관련하여 참고할만한 유사한 질문과 답변이 이미 있습니다. 아래 링크들을 참고해 보세요:

도메인 영역에 대한 질문 - 도메인 모델 구성 시 Flux 모델링에 대해 다루고 있습니다.
클린 아키텍처와 헥사고날 아키텍처 질문 - 클린, 헥사고날 아키텍처 관련된 개념을 확인할 수 있습니다.
앱에서 DDD를 적용하는 것이 맞는걸까요? - 앱 개발 시 DDD 적용에 대한 고민을 다룬 질문과 답변입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변