애그리거트에서 다른 애그리거틑 참조한다는 것은 다른 애그리거트의 루트를 참조한다는 것과 같다.
필드를 이용해 다른 애그리거트를 직접 참조하는 것은 구현의 편리함을 제공한다.
order.getOrderer().getMember().getId()JPA와 같은 ORM 기술을 이용해 애그리거트 루트에 대한 참조를 쉽게 구현할 수 있다.
하지만 다음과 같은 문제가 발생한다.
- 편한 탐색 오용
- 성능에 대한 고민
- 확장 어려움
애그리거트 내부에서 다른 애그리거트 객체에 접근이 쉽다는 것은 다른 애그리거트의 상태를 쉽게 변경할 수 있다는 것이다.
구현의 편리함으로 인해 다른 애그리거트를 수정하고자 하는 유혹에 빠지기 쉽다.
애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여 결과적으로 애그리거트의 변경을 어렵게 만든다.
JPA를 사용하면 참조한 객체를 지연 로딩과 즉시 로딩의 두 가지 방식으로 로딩할 수 있다.
상황에 맞는 다양한 경우의 수를 고려해 연관 매핑과 JPQL/Criteria 쿼리의 로딩 전략을 결정해야 한다.
사용자가 늘고 트래픽이 증가하면서 자연스럽게 부하 분산을 위해 하위 도메인별로 시스템을 분리한다.
이때 하위 도메인마다 서로 다른 DBMS를 사용할 수도 있는데, 이는 더 이상 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음을 의미한다.
ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다.
그렇기에 모델의 복잡도를 낮추고 응집도를 높여주는 효과가 있다.
또한 응용 서비스에서 필요한 애그리거트를 로딩하므로 애그리거트 수준에서 지연 로딩을 하는 것과 동일한 결과를 만든다.
외부 애그리거트를 직접 참조하지 않기 때문에 애그리거트 내부에서 다른 애그리거트의 상태를 변경할 수 없다.
성능을 고려해 조회 전용 쿼리를 사용하는 것을 고려해야 한다.
ID를 이용한 애그리거트 참조는 지연 로딩과 같은 효과를 만들기 때문에 N+1 조회 문제가 발생할 수 있다.
이를 방지하기 위해서 조회 전용 쿼리를 사용하면 된다.
여러 애그리거트를 조인으로 조회하여 한 번의 쿼리로 로딩하는 것이다.
- 세타 조인, 내부 조인, 외부 조인, 세미 조인 등 다양한 방법이 있다.
애그리거트마다 서로 다른 저장소를 사용하면 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다.
이때는 캐시를 적용하거나 조회 전용 저장소를 따로 구성해 시스템의 처리량을 높인다.
필드를 이용한 참조의 단점에 대해 설명해주고 ID 참조를 이용해 해결하는 방법을 알려주었다.
평소 조회 전용 쿼리를 자주 사용했었지만 애그리거트마다 서로 다른 저장소일 때 적용해보지 않았다.
이 경우 한 번의 쿼리로 조회할 수 없기 때문에 조회 전용 저장소 또는 캐시를 이용할 수 있다는 사실을 알게되었다.
유지 보수하기 쉽도록 하는 것이 가장 중요하다고 생각하지만 성능 또한 중요하다.
다방면으로 고려한 코드를 작성해야 비로소 좋은 코드가 된다.