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

엔티티는 도메인 모델에서 고유한 객체를 의미합니다. 따라서 도메인 모델에서 엔티티는 식별자를 가집니다. 하지만 엔티티가 아닌 다른 도메인 모델 구성요소(값 객체 등)는 식별자가 필요없죠. 그러니 도메인 모델에 식별자가 필요한 건 아니고, 엔티티로 정의되는 객체에는 식별자가 필요하다고 보면 됩니다.

도메인 모델의 핵심 구성 요소는 엔티티니 당연히 식별자를 가지고 있겠죠. DB를 매핑하는 JPA 엔티티도 엔티티입니다. 따라서 식별자(ID)를 반드시 가져야 합니다. 이건 스펙으로 강제되그 있죠. DB 테이블의 PK와 연결되어야 하고요.

결론적으로 식별자는 엔티티라면 도메인 모델에 있는 것이든, JPA 엔티티든 두어야 합니다. 이 둘을 분리하고 매핑하는 전략을 했는지에 의해서 달라지지 않습니다.

식별자를 어떤 방식으로 만들 것인가는 상당히 방대한 주제입니다. 그 중에서 내추럴/비즈니스 키가 아니라 인조키에 해당하는 자동생성된 식별자를 사용하는 방식이 여러가지 장점이 많기 때문에 보통 권장되는 편입니다. DB의 기능을 이용해도 되고, 다른 알고리즘이나 외부 서비스를 사용해도 됩니다. 선택지가 여러개라면 데이터의 규모와 사용 특성, 검색 성능 등을 고려해서 선택하시면 됩니다.

안녕하세요, 인프런 AI 인턴입니다. 10님께서 질문해주신 내용에 대해 답변드리겠습니다.

JPA 모델과 도메인 모델을 분리했을 때 식별자가 어디에 위치해야 하는지는 시스템 아키텍처와 비즈니스 요구 사항에 따라 상이할 수 있습니다. 일반적으로, 도메인 모델이 다양한 데이터 저장소와 상호작용해야 하며, 특히 RDB 외의 다른 데이터 접근 기술을 사용하는 상황에서 식별자를 도메인 모델에 두는 것은 합리적일 수 있습니다.

도메인 모델에 식별자 위치의 장단점

1. 장점:

   • 일관된 식별자 사용: 다양한 데이터 저장소(MongoDB, Redis 등) 간에 일관된 식별자를 사용할 수 있어 데이터 간의 관계를 유지할 수 있습니다.
     
   • 유연한 ID 생성: RDB에 의존하지 않고 도메인 차원의 식별자 생성 전략(UUID, Snowflake ID 등)을 사용하면 각 데이터 저장소의 특성에 맞게 유연한 관리가 가능합니다.
     

2. 단점:

   • 복잡도 증가: 각 객체에 자체 식별자를 유지하기 위해 추가 로직이 필요할 수 있으며, 이는 시스템 복잡성을 증가시킬 수 있습니다.
     
   • 관리 포인트 증가: 중앙집중식 식별자 관리를 위한 시스템 설계가 필요할 수 있으며, 이로 인해 관리 포인트가 늘어날 수 있습니다.
     

방향성에 대한 제안

식별자 생성 전략을 어떻게 가져갈 것인지는 프로젝트의 특성과 데이터 저장 특성에 따라 달라질 수 있습니다. UUID나 Snowflake ID와 같은 분산 ID 생성 메커니즘을 고려해볼 수 있습니다. 이러한 방식은 데이터 저장소의 독립성을 보장하면서도 충돌 없이 고유 식별자를 제공할 수 있습니다.

아래 토비님의 답변에서도 관련된 정보를 확인할 수 있으니 도움이 되시길 바랍니다:

• JPA Entity와 도메인 모델 분리에 대한 접근 방식
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.

현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.