인프런 커뮤니티 질문&답변
작성한 질문수
외부 API의 ID 타입(String/UUID)과 내부 도메인의 ID 타입(Long)이 불일치할 때의 설계 정석
작성
·
8
0
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.
1. 강의 내용과 관련된 질문을 남겨주세요.
2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.
(자주 하는 질문 링크: https://bit.ly/3fX6ygx)
3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.
(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.
=========================================
[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? (예/아니오)
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)
3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)
[질문 내용]
안녕하세요, 강사님! 강의를 듣다가 리포지토리 추상화와 관련하여 실무적인 고민이 생겨 질문드립니다. ( java 학습 전에 안드로이드 kotlin 개발 중에 겪었던 문제)
현재 인터페이스를 통해 리포지토리를 추상화하고, 향후 데이터 저장소가 바뀌어도 MemberService 등 비즈니스 로직을 보호하는 설계를 공부하고 있습니다. 그런데 만약 외부 시스템이나 DB의 ID 규격이 바뀌어 데이터 타입 자체가 달라지는 경우에는 어떻게 대처하는 것이 정석인지 궁금합니다.
1. 타입 불일치 및 형변환의 한계 예를 들어, 현재 우리 시스템의 도메인(Member) ID는 Long인데, 나중에 도입할 외부 API의 ID가 2131293e-r1232... 같은 UUID(String) 형태라면, 물리적으로 Long으로의 형변환 자체가 불가능합니다.
2. 이 경우 어떤 방식이 가장 권장되는 '정석'인가요?
방안 A: 도메인 모델은 우리 시스템의 기준(
Long)을 유지하고, 리포지토리 구현체 내부에서 외부 ID(String)를 별도의 필드에 매핑(저장)하며 우리만의 PK를 새로 생성한다.방안 B: 인터페이스와 도메인의 ID 타입을 처음부터 가장 범용적인
String으로 변경하여 외부 규격에 맞춘다.방안 C: 기타 실무에서 주로 사용하는 별도의 전략이 있는지 궁금합니다.
3. 고민의 요지 구현체 내부에서 '임의로 타입을 가공하거나 재조립'해서 서비스에 넘겨주는 것이 도메인의 순수성을 지키는 올바른 방향인지, 아니면 애초에 이런 타입 변경의 가능성까지 고려하여 인터페이스를 더 유연하게(예: Generic 사용 등) 설계해야 하는 것인지 강사님의 실무 노하우를 듣고 싶습니다!
답변 1
0
안녕하세요, 인프런 AI 인턴입니다.
Mia님께서 질문하신 내용은 외부 시스템과의 데이터 타입 불일치로 인한 리포지토리 및 도메인 설계에 관한 고급 주제입니다. 이 문제는 시스템 간 통합에서 빈번하게 발생하는 실무적 질문으로 중요한 내용입니다.
기본적으로 두 가지의 핵심 측면을 고려해야 합니다: 도메인 객채의 순수성과 유연성입니다.
방안별 고려사항:
방안 A (도메인 모델 유지):
이 방식은 우리 시스템의 도메인 모델의 일관성을 유지하는 데 도움이 됩니다. 외부 시스템의 ID와 내부 도메인 ID 간의 변환 논리를 리포지토리 또는 서비스 계층에서 처리할 수 있습니다. 이를 인해 외부 시스템의 변경 사항이 내부 비즈니스 로직에 미치는 영향을 줄일 수 있습니다. 하지만 변환 로직이 복잡할 수 있고, 관리해야 할 추가적인 중복 데이터가 늘어날 수 있습니다.방안 B (모든 것을 String으로):
String은 범용적인 데이터 타입이므로 외부 시스템과의 인터페이스가 용이해집니다. 하지만, 내부적으로 Long 타입의 ID를 사용하는 편리함을 잃고, 타입 안전성을 해칠 수 있습니다. 즉, 외부 API와의 연동에는 용이하나, 내부 도메인의 특정 ID 처리 로직 구현이 복잡해질 수 있습니다.방안 C (기타 전략 - Generic 사용):
제네릭 클래스를 사용하여 ID 타입을 유연하게 설정할 수 있는 인터페이스는 미래의 변화에도 적응하기 쉽습니다. 이 방식은 초기 설계가 복잡할 수 있지만 한 번 구축되면 다양한 케이스에 재사용 가능하며 유지보수에 강점이 있습니다. 다만, 모든 경우에 제네릭이 적합한 것은 아니며, 특히 복잡성을 증가시킬 수 있습니다.
추천
실무에서 권장되는 접근 방식은 상황에 따라 다르지만, 일반적으로 타입의 유연성을 확보하면서도 현재 시스템의 도메인 모델 순수성을 유지하는 방법이 선호됩니다. 따라서 방안 A 또는 방안 C를 사용해볼 수 있습니다.
- 도메인 모델의 순수성: 우리 시스템 내에서의 데이터 일관성과 비즈니스 로직의 명확성을 유지합니다.
- 유연한 외부 연동: 변환과 매핑 로직을 외부와의 경계 (예: 리포지토리 계층)에 위치시킴으로써 외부 변화에 더욱 유연하게 대응할 수 있습니다.
유사한 질문을 다루고 있는 기존 답변이 있습니다. 확인해보시면 더욱 도움이 되실 것 같습니다:
- 안녕하세요 궁금한게 있어서 질문 하나 드려봅니다!!!
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.