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

안녕하세요. bebe님, 공식 서포터즈 y2gcoder입니다.

맞습니다. 초반에는 비즈니스 요구사항을 잘 충족할 수 있는 정도의 개념적 모델링 정도로 충분한 것 같습니다.

추상화, 분리 등의 각종 리팩토링을 하는 것도 결국 비용이 드는 작업입니다.

간단하게는 다른 기능적인 추가를 할 수 있던 시간을 기회비용으로 사용하는 것입니다 🙂 또한 실제로 열심히 나눴는데 생각보다 해당 데이터들을 분리해서 보여줄 일이 많지 않고, 오히려 같이 보여줘야 할 일이 많아서 조인 비용만 더 드는 경우도 있습니다!

특히 말씀해주신 케이스들인 1:1 관계에서는 그런 일이 더 많은 것 같습니다. 이러한 부분을 비즈니스 요구사항이나 설계 등에서 잘 고려해보시고 결정하시길 권해드립니다.

감사합니다.

안녕하세요, 인프런 AI 인턴입니다.
bebe님께서 질문하신 엔티티 분리의 기준에 대해 답변드리겠습니다.

엔티티를 분리할 때 고려해야 할 몇 가지 요소는 다음과 같이 정리할 수 있습니다:

1. 비즈니스 요구사항: 기본적으로 비즈니스 요구사항이 어떤지를 먼저 고려해야 합니다. 예를 들어, 주문과 배송은 완전히 다른 프로세스라면 각 프로세스가 독립적으로 관리될 수 있도록 엔티티를 분리하는 것이 좋습니다.

2. 데이터 접근 패턴: 엔티티를 분리함으로써 응용 프로그램의 성능이 향상될 수 있습니다. 예를 들어, 특정 기능에서는 회원의 (이메일, 비밀번호) 정보만 자주 조회된다면, 해당 정보를 별도로 분리하여 관리하는 것이 더 효율적일 수 있습니다.

3. 변경의 용이성: 엔티티를 잘못 분리하면, 변경할 때마다 많은 코드 수정이 필요할 수 있습니다. 따라서 이렇게 변경이 빈번한 경우에는 엔티티를 유연하게 설계하여 필요한 부분만 수정할 수 있도록 하는 것이 좋습니다.

4. 복잡성의 정도: 너무 많은 엔티티로 설계를 시작하면 오버엔지니어링의 위험이 있습니다. 초기 단계에서는 핵심 비즈니스 로직을 우선에 두고 설계하고, 이후 필요에 따라 세부적인 부분을 조정하는 방법을 추천드립니다.

엔티티 분리에 관한 더 깊은 논의를 원하신다면, 이 질문에서 다루고 있는 1:1 연관관계를 유지할 때의 고려사항도 도움이 될 수 있습니다. 백린이님이 질문한 내용과 관련된 답변을 통해 엔티티 분리의 기준을 한 번 더 확인하실 수 있습니다.

결론적으로, 모든 것을 처음부터 고려할 필요는 없으며, 비즈니스 요구사항과 데이터 액세스 패턴을 기반으로 설계를 시작한 후 개발 중에 유연하게 조정하는 접근이 효과적입니다.

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