DTO 사용하는 이유

먼저 DTO란 Data Transfer Object의 약자다.

말 그대로 데이터를 이동하기 위한 객체다.
처음 DTO를 봤을 때 이게 왜 필요하지? 왜 이렇게 해야 하지?

라는 생각에 잘 사용하지도 못했고, 책 보고 클론 코딩할 때나 사용했다.

하지만 DTO의 장점을 찾고 목적을 가지고 잘 사용하기 위해서 정리해두려고 한다.

내가 처음 DTO를 알게 되고 사용을 고민하게 된 이유는 클라이언트에서
JSON 형태로 요청이 왔을 때 이것을 내가 자바 세상에서 사용하기 위해서 방법을 찾아보니
직렬 화, 역직렬 화 라는 개념을 알게 되었다.

한 줄로 요약한다면

💡 직렬화 : 객체 데이터를 전송 가능한 형태(JSON, XML, 바이너리…)로 변환하는 과정 (객체 → JSON)

💡역직렬화 : 직렬화된 데이터를 다시 객체 형태로 변환하는 과정 (JSON → 객체)

나는 최초에 역직렬화 방법을 찾다가, DTO를 알게 되었다.
그 순간에 꼭 DTO를 만들어서 사용해야 할까? 그냥 Entity(Model) 객체의 멤버와 동일한 내용을
요청을 통해 받아올 텐데 하는 메소드에서 DTO는 사용하지 않아도 된다는 생각을 했다.

하지만 조금만 더 생각하고 찾아보니 그리 좋은 방법은 아니었음을 깨달았다.

DTO를 어떻게 사용해볼까!

RQ_DTO : RequestDto
RS_DTO : ResponseDto

1. Entity가 Request의 요청을 받는 처리를 하는 책임까지 추가하는 것은 아니다.

   • 단일책임 (SRP) 관점에서 Entity가 RequestBody의 값을 받아 객체화 되고,
     Controller -> Service -> Repository 까지 이동하면서 데이터 이동, 관리한다는 점이
     딱 보기에도 많아보인다.
     내가 생각하기에는 단일책임이란 수정되어야할 이유가 하나이고 액터도 하나여야한다.
   • 수정될 이유가 2개 이상
     1. DB가 저장할 데이터 목록이 바뀌는 일은 거의 없겠지만, 만약 바뀐다면 Entity 객체를 수정해야한다. (액터 1 :DB)
     2. 클라이언트가 요청할 때 보낼 데이터가 바뀐다. Entity에를 수정해야한다. (액터 2 : 클라이언트)

2. RequestBody,ReponseBody의 내용과 모델 객체의 멤버가 1 대 1 대응이 된다는 보장이 없다.
   Ex: 생성 단계에는 필요 없는 정보가 이후에 추가될 수 있는 경우 등..
   Entity는 생성시간,업데이트 시간등이 있는데 Client는 이런 정보가 필요하지 않을 수 있다.

3. 모델 객체가 Controller → Service → Repository 모든 단계를 움직이면서
   내부 데이터가 변할 수 있는 상황에 노출되는 것은 좋지 않다.

4. 클라이언트의 요구 사항은 생각보다 변동이 많다. 동적인 요구에 대응하기 쉽게 DTO를 두어
   해당 클래스만 수정한다.

5. 나는 requestDTO, responseDTO 가 분리되어 있을 거라고 생각하지 못했다.
   하지만 너무 당연하지 않은가? 요청할 때의 데이터 형태와, 응답의 형태가 같을 일은 거의 없다.

6. 정말 객체만을 이동시켜주는 객체 DTO가 존재한다면 유지보수가 쉽다.

나는 솔직히 아직 누구 신지는 잘 모르지만, 마틴 파울러님께서

DTO의 주요 목적은 한 번의 호출로 여러 매개 변수를 함께 처리해서 서버의 왕복을 줄이는 것

이라고 하셨는데 내가 이해한 것이 맞는다면 DTO를 사용하지 않는 경우 서버에서는 필요한 데이터를 모두
받기 위해 클라이언트한테 3~4번의 요청을 받아야 하는데, DTO를 두어 3~4번 요청으로 받을 데이터를
한번에 받아서 통신과정에서 발생하는 시간을 절약하자는 의미로 이해했다.

이 뜻이 아니더라도 내가 정리한 2번과 같이 1대 1 대응이 된다는 보장이 없어서 DTO를 사용하는 것이 중요하다고 생각한다.

---

⭐틀린 내용 수정,지적은 언제나 환영합니다.⭐