강의

멘토링

커뮤니티

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

ㅎㅇㅎㅇㅎㅇ님의 프로필 이미지
ㅎㅇㅎㅇㅎㅇ

작성한 질문수

토비의 클린 스프링 - 도메인 모델 패턴과 헥사고날 아키텍처 Part 1

Entity vs DTO

애플리케이션의 JPA 리턴과 도메인 모델

작성

·

42

·

수정됨

0

안녕하세요 토비님 강의 잘 수강하고 있습니다. 좋은 강의 감사드립니다.


 

저는 JPA엔티티를 도메인 모델로 사용하고 애플리케이션에서 이를 리턴하고 있습니다.

그런데 새로운 팀원 한명이 이렇게 이야기하더군요

이전에 마이바티스를 사용하다가 JPA가 나온거처럼 이를 대체하려면 코드변화가 필요할 것 입니다

 

사실 이것도 저는 맞는 말이라고 생각합니다. JPA 엔티티를 참조하는 모든 부분을 수정이 필요할 것 같습니다. 그럼에도 불구하고, 트레이드오프 관점에서 보면 현재 잘 사용하는 JPA엔티티를 그대로 사용하는게 더 효과적이라고 생각합니다.

 

여기서 궁금한게, 이렇게 새로운 데이터접근 기술이 나오게 되는 것까지 고려하는게 맞을까요? 어떠한 논리를 펼쳐서 JPA를 그대로 의존하는게 좋다고 이야기하는게 더 설득력이 있을까요?

답변 2

0

토비님의 프로필 이미지
토비
지식공유자

도메인 모델에 적용된 기술의 변경은 꽤 큰 변화입니다. MyBatis에서 JPA로의 변화는 단순히 저장 기술의 변화 이상이죠. 이전엔 DB 테이블의 구조에 종속적인 바인딩 모델을 썼다면, JPA는 그 부분을 더 유연하게 매핑할 수 있고(테이블과 엔티티가 1:1이 아니어도 가능하니까요), 도메인 모델에 충실하게 엔티티를 설계할 수 있는 기회를 제공해줬습니다. 이런 변화는 이후에 저장 기술이 다시 변경되더라도 JPA 시절에 만든 도메인 엔티티(이게 JPA용으로 현재 쓰이지만, 애노테이션만 무시한다면 이후 다른 기술을 쓰더라도 그대로 사용 가능합니다. JPA 엔티티는 실행 기능과는 무관한 애노테이션을 제외하고 코드만 보자면 JPA 기술에 종속적이지 않고, 오히려 도메인 설계에 충실하게 작성 가능하니까요.

애플리케이션에서 엔티티를 리턴하는 것이 더 나은 선택이라는 제 의견은, 반대로 웹 계층에 종속된 DTO를 애플리케이션이 매번 알고 의존하지 않는 게 더 낫기 때문입니다. 엔티티 대신, 엔티티와 동일한 구조를 가졌지만 읽기 전용으로 만들어진 불변 DTO에 매번 매핑해서 리턴해도 같은 효과를 볼 수 있습니다. 하지만 이 방법이 주는 이익에 비해서 수고롭고, 버그가 들어갈 가능성이 높아지고, 매우 번거롭죠. 그래서 엔티티를 애플리케이션에서 리턴할 때는 정보를 전달하는 오브젝트로 사용하는 선택을 한 것입니다.

도메인 모델을 중심에 두고 개발하는 방식을 포기하지 않는다면, 저장 기술이 변경된다 하더라도 JPA 엔티티를 리턴하는 구조로 만들었던 코드는 거의 변경이 필요없을 겁니다.

아아 이해되었습니다! 자세한 설명 감사드립니다!!

0

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

강의를 수강하시면서 JPA 엔티티를 도메인 모델로 사용하는 것에 대한 고민을 공유해 주셨네요. JPA 엔티티를 도메인 모델로 사용할 때 데이터 접근 기술이 변경될 가능성에 대한 걱정을 하실 수 있습니다. 이러한 결정은 시스템의 복잡성과 변경의 용이성 등을 고려하여 판단해야 합니다.

JPA 엔티티를 도메인 모델로 사용하는 이유:

  1. 생산성과 효율성: JPA는 강력한 ORM으로, 데이터베이스와 객체 모델 간의 매핑을 자동으로 처리해주기 때문에 많은 개발 시간을 절감할 수 있습니다. 이는 복잡한 쿼리 작성 및 데이터베이스 관리 작업을 줄이는 데 매우 유리합니다.

  2. 일관성 있는 API 제공: JPA를 사용하면 표준화된 API를 통해 데이터베이스 작업을 수행할 수 있습니다. 이는 팀 내에서 일관된 코드 스타일을 유지하고, 코드 리뷰 및 유지보수를 용이하게 합니다.

  3. 지속 가능한 기술: JPA는 널리 사용되는 기술로서, 많은 개발자 커뮤니티와 지원이 있기에 장기간에 걸쳐 신뢰할 수 있는 생태계를 제공합니다.

새로운 데이터 접근 기술 고려 시:

  • 기존 코드의 변경 부담: 새로운 기술을 도입하면 기존 코드베이스의 많은 부분이 변경되어야 할 수 있습니다. 이는 주요 리팩터링 작업이 필요함을 의미하며, 그로 인한 위험과 시간을 고려해야 합니다.

  • 학습 곡선: 팀원들이 새로운 기술을 학습하고 적응하는 데 시간이 필요할 수 있습니다. 이는 일시적인 생산성 저하로 이어질 수 있습니다.

  • 기술의 안정성 및 커뮤니티 지원: 새로운 기술이 안정적이고 널리 사용되는지, 충분한 커뮤니티 지원 및 문서가 있는지도 중요합니다.

현재 특정 요건이나 성능상의 이슈로 인해 기술 전환을 고려해야 할 명확한 필요성이 없다면, 잘 작동하는 JPA를 유지하고 관련 기술을 지속적으로 개선해 나가는 것이 더 실질적일 수 있습니다. 기술 전환은 큰 프로젝트의 경우 많은 리소스와 시간이 필요한 만큼 신중한 계획과 평가가 필요합니다.

이와 관련된 토비님의 기존 응답을 참조하시면 더 많은 인사이트를 얻으실 수 있습니다. 만약 JPA와 도메인 모델의 사용에 대한 더 구체적인 예시나 실무에서의 접근법이 궁금하시다면, 아래 유사한 주제를 다룬 내용을 참고하시면 좋습니다:
- JPA Entity와 도메인 모델에 대한 선택 및 고려 사항

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

ㅎㅇㅎㅇㅎㅇ님의 프로필 이미지
ㅎㅇㅎㅇㅎㅇ

작성한 질문수

질문하기