[주문조회 4V; jpa에서 DTO 직접 조회] 응답으로 DTO 전달 시, enum 과 값 타입 포함 관련

Question

안녕하세요, 강의에서 궁금한 점이 있어 질문 드립니다.

응답으로 엔티티를 그대로 반환하는 것이 아닌,
DTO 를 반환하는 이유 중 하나가
엔티티 변경 시, API 스펙에도 영향이 가는 것을 방지하기 위함이라고 이해했습니다.

그렇다면,
4:35 분 경, OrderQueryDto 를 구성할 때,
Entity 에서, 해당 값들을 받아올 때,

1) Address 와 같은 값 타입이나,
OrderStatus 와 같은 enum 들도, 별도의 Dto 로 만들어서 반환해야 되는것인지,

2) 그게 아니라면,
값 타입이나, Enum 값은 변경이 별로 없다는 것을 전제로 하고, 그대로 내려줘도 되는 것일지

3) 둘 다 이유가 될 경우, 최종적으로는,
회사 별 코드 스타일대로 따르면 될지 질문드려요.

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. 김지환님. 질문해주신 내용은 강의에서 DTO를 반환할 때, 관련된 값 타입과 Enum을 어떻게 처리하는지에 대한 것입니다. 아래에 관련 질문과 답변들을 소개해 드리니 참고해 주세요. 값 타입과 Enum을 DTO로 변환해야 하는가? 엔티티에서 Address 생성자 선언보다 DTO에서 생성자를 만들어야하지 않나요? - 엔티티의 값 타입이나 Enum을 DTO로 변환할 필요가 있는지에 대한 논의가 이루어졌습니다. 일반적으로 값 타입이나 Enum은 도메인 계층에 정의되어 있어, 변경될 가능성이 적습니다. 따라서 그대로 사용해도 무방하다는 의견이 많습니다. DTO로 변환해야 한다면, 그 이유는 무엇인가요? Entity 메소드 파라미터로 DTO를 받는 것, 괜찮을까요? - 변경 가능성과 응집도를 고려하여, 엔티티 변경을 통한 API 스펙 변경을 최소화하려는 목적에서 DTO로 변환하는 방법도 고려됩니다. 회사 내 코드 스타일에 따라 결정해야 하는가? domain쪽 enum값 계층 질문 - 대부분의 경우, 회사의 코드 스타일이나 협업 규칙에 따라 결정하는 것이 좋다는 의견도 있습니다. 그렇게 하면 팀 내에서 일관되게 코드를 관리하고 유지보수하는데 유리합니다. 결국, 어떻게 처리할지는 이러한 고려사항들을 바탕으로 팀이나 회사의 규칙에 따라 결정하시는 것이 좋습니다. 유연하게 접근하면서도, 팀 내에서 합의된 방식으로 유지하는 것이 중요합니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.