Member와 MemberDetail 엔티티를 나누는 기준에 대해

안녕하세요.
강의 정말 잘 들었습니다. 강의를 듣다가 궁금한 점이 있어 질문 남깁니다.

Member와 MemberDetail을 별도 엔티티로 분리한 기준이 궁금합니다.

관계가 1:1인 경우에는 엔티티에 너무 많은 필드가 있는 것이 아니면 하나로 관리하는 게 더 개발 편의성이 좋지 않을까? 하는 생각이 들기도 합니다. 실제로 회원 정보 수정 시에 닉네임, 프로필 주소, 자기소개를 한 번에 변경하도록 구현되어 있어, 두 엔티티가 함께 조회/수정되는 것처럼 보입니다.

혹시 조회 성능 최적화를 위해 접근 빈도가 낮은 데이터를 지연 로딩하려는 의도인지, 아니면 회원의 본질적 속성(email, status 등)과 부가 정보(등록일시, 프로필 등)를 개념적으로 구분하기 위한 설계인지 궁금합니다.

감사합니다.

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

Member와 MemberDetail을 별도의 엔티티로 분리한 이유에 대해 궁금증을 갖게 되셨군요. 이러한 결정은 여러 아키텍처 및 설계 원칙에 근거하여 이루어지는데, 중요한 몇 가지 고려 사항을 말씀드리겠습니다.

비즈니스 로직의 복잡성:
- 엔티티를 분리함으로써 각각의 도메인 개념을 명확히 하고, 비즈니스 로직을 분리하여 관리하기 용이합니다. 예를 들어, Member는 회원의 본질적인 데이터, MemberDetail은 추가적인 메타데이터로 보는 것이 일반적입니다.
응집성과 결합도:
- 엔티티의 응집성을 높이고, 결합도를 낮추기 위해 속성의 중요도에 따라 분리하여 디자인했습니다. 이는 코드의 가독성과 유지보수성을 크게 향상시킵니다.
데이터 접근 및 성능:
- 데이터 접근 빈도가 다른 필드 저정을 두 엔티티로 나누는 것이 성능 최적화에 도움이 될 수 있습니다. 자주 접근하지 않는 정보를 지연 로딩(Lazy Loading)하여 자원 낭비를 줄이려는 목적도 있습니다.
확장과 변경 용이성:
- 시간이 흐름에 따라 요구사항이 변경되더라도 서로 독립적인 엔티티들은 변경 영향 범위를 줄여 더욱 안정적인 유지보수 환경을 제공합니다.

관련 내용은 다음 게시물에서도 확인하실 수 있습니다:

이러한 관점을 기반으로 설계된 엔티티 구조는, 도메인 로직에 가장 적절한 형태로 데이터와 비즈니스 로직을 관리하려는 토비님의 설계 철학을 잘 반영한 결과입니다. 이해하시는 데 도움이 되었길 바랍니다.

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

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