선생님 질문 있습니다.

안녕하세요 종민님! 크으~ 정말 좋은 질문이십니다! 👍

결론부터 말씀드리면, 스프링 프레임워크에서 강제하는 부분은 아니고
User를 바로 노출하는 것보다 DTO를 만들어 반환하는 것이 안전하고 확장가능성 있기 때문입니다!

설명 한 번 드려보겠습니다~~~!!

위의 그림과 같이 User 를 UserResponse 로 변환하지 않고 User 를 바로 사용했다고 해보겠습니다. 그렇다면 지금 당장은 큰 문제가 없어 보여요! 실제로도 name과 age만 가지고 있고, 해당 정보를 API로 잘 넘겨주면 되기에 문제가 없습니다.

그런데 이런 요구사항이 생겼다고 상상해보겠습니다.

• 우리 이제 로그인 기능을 추가하자~ 이메일과 비밀번호 필드가 추가되어야 해!

• 이메일과 비밀번호는 개인정보니까 API에는 name과 age만 반환해야해!

현재 User 를 표현하는 객체는 단 한 개이므로 email과 password는 User 객체에 추가되고 별도의 조치를 하지 않으면 (벌써 조치를 해야 한다는 것부터 번거롭습니다! 😭) 소중한 개인정보인 email과 password가 애플리케이션 외부로 노출되게 됩니다.

또한, 객체지향적인 관점으로 볼 때도 User 객체는 두 가지 일을 하고 있게 됩니다. (관련 내용은 17강에서 다루고 있습니다!)

1. API 외부로 보여줄 필드를 관리

2. 내부의 비즈니스 로직을 처리하기 위한 필드를 관리

   1. 물론 8강까지는 요구사항이 매우매우 간단하기에 비즈니스 로직이라 부를만한게 없습니다 ㅎㅎㅎㅎ...

이 역할을 User 와 UserResponse 로 쪼개면 다음과 같은 상황이 됩니다!

User는 비즈니스 로직 처리를 위한 필드들만 가지고 있고 UserResponse 는 애플리케이션 외부로 노출할 필드만을 가지고 있게 되어 책임과 경계가 더욱 분명해졌고,

이 덕분에 email과 password 같은 소중한 필드는 애플리케이션 내부에 숨길 수 있게 되었습니다!

이때 User 와 같은 객체를 '도메인 객체'라고 불러요!!

우리가 어떤 기능을 구현하기 위해 main으로 참여하는, 주요 관심사인 객체이죠

위와 같은 이유로 도메인 객체와 DTO를 구분하는 것이 좋다고 할 수 있습니다 👍

혹시나 또 궁금하신 내용 있으시면 질문 남겨주세요! 감사합니다!! 🙏🙏

답변 감사합니다!

친절한 답변 감사합니다!

좋은 질문과 답변 퀄리티에 감동하여 좋아요 누르고 갑니다..