Inflearn Community Q&A
asked
Member와 MemberDetail 엔티티를 나누는 기준에 대해
Resolved
Written on
·
36
0
안녕하세요.
강의 정말 잘 들었습니다. 강의를 듣다가 궁금한 점이 있어 질문 남깁니다.
Member와 MemberDetail을 별도 엔티티로 분리한 기준이 궁금합니다.
관계가 1:1인 경우에는 엔티티에 너무 많은 필드가 있는 것이 아니면 하나로 관리하는 게 더 개발 편의성이 좋지 않을까? 하는 생각이 들기도 합니다. 실제로 회원 정보 수정 시에 닉네임, 프로필 주소, 자기소개를 한 번에 변경하도록 구현되어 있어, 두 엔티티가 함께 조회/수정되는 것처럼 보입니다.
혹시 조회 성능 최적화를 위해 접근 빈도가 낮은 데이터를 지연 로딩하려는 의도인지, 아니면 회원의 본질적 속성(email, status 등)과 부가 정보(등록일시, 프로필 등)를 개념적으로 구분하기 위한 설계인지 궁금합니다.
감사합니다.
Answer 2
0
보통 애그리거트로 취급하면서 lazy로 연결된 서브 엔티티를 두는 경우엔 해당 속성에 대한 조회, 변경 가능성을 보고 판단합니다. Member나 User 처럼 에티티가 많은 다른 엔티티에 연결되어 사용되는 경우 매번 디테일에 해당하는 정보를 로딩하는 것은 성능면에서 좋지 않겠죠.
Member를 살펴보면 조회가 변경 보다 압도적으로 많다고 생각됩니다. 그런 면에서 거의 모든 화면에서 한번씩은 읽게 되는 Member의 기본 정보(이메일, 닉네임 등등)는 애그리거트 루트 엔티티에 넣고, 특별한 화면에서만 조회하는 데이터는 Detail로 분리하는 게 적절해 보입니다.
변경은 생각보다 자주 일어나지 않습니다. 그때는 cascading에 의해서 두 번 읽어도 되고, Detail까지 함께 읽는데 여러 Member 정보를 한번에 가져오는, 대표적으로 관리자 화면인 경우엔 fetch join을 사용하면 1:1로 연결된 테이블까지 쿼리 한번에 가져오기 때문에 성능에 영향은 미미합니다.
본질적인 속성인지 부가적인 것인지는 개발을 계속하면서 판단해야 할 것으로 보입니다. 개발하다보면 Detail에 있는 속성이 비번하게 조회되거나 변경되는 경우가 있다면 이를 Member로 옮기는 리팩터링을 해도 좋습니다.
조회 빈도가 다르다는 것은 속성이 가지는 의미와 쓰임새가 다르기 때문이라고 봅니다. 그래서 빈도에 따른 부분 접근으로 인한 성능 최적화와 로직에 해당하는 코드를 그 속성과 가까운 쪽에 두는 두 가지가 다르게 결정된다고 보지 않습니다. 물론 외부에서 볼 때 주요 로직에 해당하는 변경 부분은 루트 엔티티를 통해서만 일어나기 때문에 애그리거트 내부에 어느 위치에 해당 정보가 저장되는지는 중요하지 않습니다.
0
안녕하세요, 인프런 AI 인턴입니다. 나는님!
Member와 MemberDetail을 별도의 엔티티로 분리한 이유에 대해 궁금증을 갖게 되셨군요. 이러한 결정은 여러 아키텍처 및 설계 원칙에 근거하여 이루어지는데, 중요한 몇 가지 고려 사항을 말씀드리겠습니다.
비즈니스 로직의 복잡성:
- 엔티티를 분리함으로써 각각의 도메인 개념을 명확히 하고, 비즈니스 로직을 분리하여 관리하기 용이합니다. 예를 들어,
Member는 회원의 본질적인 데이터,MemberDetail은 추가적인 메타데이터로 보는 것이 일반적입니다.
- 엔티티를 분리함으로써 각각의 도메인 개념을 명확히 하고, 비즈니스 로직을 분리하여 관리하기 용이합니다. 예를 들어,
응집성과 결합도:
- 엔티티의 응집성을 높이고, 결합도를 낮추기 위해 속성의 중요도에 따라 분리하여 디자인했습니다. 이는 코드의 가독성과 유지보수성을 크게 향상시킵니다.
- 엔티티의 응집성을 높이고, 결합도를 낮추기 위해 속성의 중요도에 따라 분리하여 디자인했습니다. 이는 코드의 가독성과 유지보수성을 크게 향상시킵니다.
데이터 접근 및 성능:
- 데이터 접근 빈도가 다른 필드 저정을 두 엔티티로 나누는 것이 성능 최적화에 도움이 될 수 있습니다. 자주 접근하지 않는 정보를 지연 로딩(Lazy Loading)하여 자원 낭비를 줄이려는 목적도 있습니다.
- 데이터 접근 빈도가 다른 필드 저정을 두 엔티티로 나누는 것이 성능 최적화에 도움이 될 수 있습니다. 자주 접근하지 않는 정보를 지연 로딩(Lazy Loading)하여 자원 낭비를 줄이려는 목적도 있습니다.
확장과 변경 용이성:
- 시간이 흐름에 따라 요구사항이 변경되더라도 서로 독립적인 엔티티들은 변경 영향 범위를 줄여 더욱 안정적인 유지보수 환경을 제공합니다.
- 시간이 흐름에 따라 요구사항이 변경되더라도 서로 독립적인 엔티티들은 변경 영향 범위를 줄여 더욱 안정적인 유지보수 환경을 제공합니다.
관련 내용은 다음 게시물에서도 확인하실 수 있습니다:
이러한 관점을 기반으로 설계된 엔티티 구조는, 도메인 로직에 가장 적절한 형태로 데이터와 비즈니스 로직을 관리하려는 토비님의 설계 철학을 잘 반영한 결과입니다. 이해하시는 데 도움이 되었길 바랍니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
성능에서 조회 최적화가 가장 중요한 핵심인 것 같습니다. 업무를 할 때 이런 부분들을 고민하면서 도메인 설계를 해보도록 하겠습니다. 답변 감사합니다!