JPA 모델과 도메인 모델을 분리했을 때 식별자는 어디에 두는 게... - 인프런

안녕하세요 토비님 🙃

여러 데이터 접근 기술을 병행해야 하는 상황에서, 도메인 모델과 JPA 모델을 분리해서 관리하고 있습니다.

이때 한 가지 궁금증이 생겼습니다.

RDB 외의 데이터 접근 기술(예: Redis, MongoDB 등)을 고려하면 도메인 모델에서도 식별자(ID) 개념이 필요할 것 같은데, 이런 경우 도메인 객체가 ID를 직접 가지는 것이 괜찮을까요?

만약 괜찮다면, 이는 RDB의 책임(시퀀스, AUTO_INCREMENT 등)에 위임하지 않고, 별도의 UUID나 Snowflake ID 등 도메인 차원의 식별자 생성 전략을 두어야 할 것 같은데 이런 방향성에 대해 어떻게 생각하시는지 궁금합니다.

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

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

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

장점:
- 일관된 식별자 사용: 다양한 데이터 저장소(MongoDB, Redis 등) 간에 일관된 식별자를 사용할 수 있어 데이터 간의 관계를 유지할 수 있습니다.
- 유연한 ID 생성: RDB에 의존하지 않고 도메인 차원의 식별자 생성 전략(UUID, Snowflake ID 등)을 사용하면 각 데이터 저장소의 특성에 맞게 유연한 관리가 가능합니다.
단점:
- 복잡도 증가: 각 객체에 자체 식별자를 유지하기 위해 추가 로직이 필요할 수 있으며, 이는 시스템 복잡성을 증가시킬 수 있습니다.
- 관리 포인트 증가: 중앙집중식 식별자 관리를 위한 시스템 설계가 필요할 수 있으며, 이로 인해 관리 포인트가 늘어날 수 있습니다.

방향성에 대한 제안

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

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

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

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

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

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

JPA 모델과 도메인 모델을 분리했을 때 식별자는 어디에 두는 게 맞을까요❓

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

방향성에 대한 제안