ImprovedOrder의 구조에 대한 질문입니다.

6주 완성! 백엔드 이력서 차별화 전략 4가지 - 똑같은 이력서 속에서 돋보이는 법

3-10. 실제 예시 코드로 작성하기 -2

해결된 질문

작성

우선 orderResponse에서는 totalItems만 사용해서 수량만 요구하는 DTO
OrderDetailResponse에서는 List<OrderItemResponse> items; 물품 정보를 요구하는 DTO 용으로 나뉘어 있고
Improved 역시 마찬가지였습니다.

그런데 toOrderDetailResponse에서

orderItems가 매핑이 안되어 있고, toOrderResponse와 코드가 동일한 상태였습니다. 제 생각에는 totalItems에 집중하신 나머지 빠뜨리신 거라고 생각되어 글을 남기게 되었고, 현재 ImprovedOrder에 orderItem이 매핑되어 있지 않은 상태 즉 반정규화 상태에서 어떻게 OrderItem을 매핑하는게 좋을지 생각해봤습니다.

1. orderNumber로 findByOrderNumber

단순히 ImprovedOrder에 저장된 orderNumber로 따로 orderItem들을 찾고 매핑해주는 것입니다. 현재 반정규화 의도가 totalCount만을 요구하는 도메인이 중요하기 때문에 ImprovedOrderDetailResponse를 반환할 때만 따로 매핑하는 것이죠. 다만 이는 ImprovedOrder와 OrderItem이 분명한 관계가 있음에도 매핑이 되어 있지 않는 것이라 좋은 방법인지는 의문입니다.

2. ImprovedOrder에 orderItem 필드 추가

totalItems와 orderItems를 모두 가지게 하고 totalItems만 필요한 상황이라면 굳이 orderItems를 get하지 않으면 Lazy 상태이기 때문에 fetch가 발생하지 않아 유연하게 사용할 수 있지 않을까 생각했습니다.

포트폴리오를 위해 분석하던 과정에서 의문이 생겨 질문드렸습니다. 만약 제가 잘못 생각하고 있다면 말씀해주세요.

java spring mysql redis 이력서

답변 2

딩코딩코

지식공유자

안녕하세요 gogoDevelop님!! 열공하시는 모습 아주 좋습니다 🔥

반정규화와 관련된 좋은 고민을 하고 계시는군요!!

제가 보기에는 두 번째 방법인 "ImprovedOrder에 orderItems 필드 추가"가 더 좋은 방향인 것 같습니다.

반정규화를 했다고 해서 객체 간의 관계를 완전히 끊을 필요는 없습니다!. JPA의 장점은 객체 관계를 자연스럽게 표현할 수 있다는 건데, 이걸 포기하는 건 아쉬울 것 같습니다.

게다가 totalItems만 필요한 경우에는 orderItems를 불러오지 않으니까 FetchType.LAZY로 설정하면 성능상 이점도 그대로 누릴 수 있습니다. 필요할 때만 orderItems를 조회하게 되니 반정규화의 성능 이점은 유지하면서도, 필요할 때는 관계를 활용할 수 있을 것 같습니다.

첫 번째 방법(orderNumber로 별도 조회)도 가능하긴 하지만, 결국 N+1 문제가 다시 발생할 수 있고, 명확한 관계가 코드에 표현되지 않아서 좀 아쉬운 부분이 있습니다.

결론적으로, totalItems 같은 자주 쓰는 정보는 반정규화해서 성능을 확보하고, 동시에 orderItems와의 관계도 LAZY로 유지해서 필요할 때만 사용하는 방식이 균형 잡힌 접근법이라고 생각합니다!!

좋은 질문 해주셔서 감사합니다!!

gogoDevelop

질문자

2번과 같은 구조가 올바른지 긴가민가 했었는데 감사합니다.

딩코딩코

지식공유자

좋은 의문 가져주셔서 좋습니다!! 언제든 질문해주세용

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. gogoDevelop님.

ImprovedOrder의 구조 및 매핑에 대한 질문을 주셨네요. 현재 ImprovedOrder에서 OrderItem에 대한 매핑이 없다면, 이를 어떻게 해결할지 고민하시는 것 같습니다. 두 가지 접근 방식을 제안하셨는데, 두 접근 방식 모두 각각의 장단점이 있습니다.

1. findByOrderNumber로 매핑

장점: ImprovedOrder와 OrderItem이 강하게 결합되지 않아서 설계를 간단하게 유지할 수 있으며, 필요할 때만 OrderItem을 로드할 수 있습니다.
단점: OrderItem을 가져올 때마다 추가적인 데이터베이스 쿼리가 발생할 수 있습니다. 이는 성능에 영향을 줄 수 있습니다.

이 방법은 성능을 고려하여 필요할 때만 데이터를 가져오는 것을 선호하실 경우 적합합니다. 하지만 만약 관련 OrderItem들이 자주 필요하다면, 이 접근 방식은 반복되는 데이터베이스 호출을 초래할 수 있습니다.

2. ImprovedOrder에 orderItem 필드 추가

장점: OrderItem이 ImprovedOrder에 매핑됨으로써 더 자연스러운 객체 모델링이 이루어질 수 있습니다. 필요 시점에 데이터를 로드하거나, 필요 없는 경우 지연 로딩을 활용하여 데이터를 가져오지 않도록 할 수 있습니다.
단점: 객체 간의 강한 결합으로 인해 설계가 복잡해질 수 있으며, 데이터를 잘못 사용하는 경우 성능 저하가 있을 수 있습니다.

이 방법은 특히 전체 OrderItem 목록이 자주 필요할 경우 적합하며, Lazy Loading을 통해 참조가 부족한 경우 성능 저하를 방지할 수 있습니다.

선택 기준

타협점을 찾는 것이 중요합니다. 저장소 또는 서비스 레이어에서 두 접근 방식을 혼합하여 사용할 수도 있습니다. 예를 들어, 대부분의 경우 첫 번째 방법을 사용하고, 성능이 중요해지는 곳에서는 두 번째 방법(필드 추가 및 지연 로딩)을 사용하는 것입니다.

관련 이미지와 코드들을 참고하려면 다음 링크들을 활용해보세요:
- toOrderDetailResponse method 작성 확인하기
- ImprovedOrder class definition

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏

추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

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