DTO에 대한 고민

저번 주에는 카카오 테크 캠퍼스 2단계 과제 수행을 기회로 평소 DTO에 관해 고민한 것을 정리해보는 시간을 가졌습니다!!

 

DTO는 Data Transfer Object 즉, 데이터를 전달할 때 사용하는 객체입니다.

 

 

 

먼저, 첫 번째 고민이었습니다.

과연 DTO를 사용하면 어떤 이점을 얻을 수 있는 걸까요?

 

1. 단일 호출 시 여러 매개변수를 일괄처리하여 네트워크의 오버헤드를 줄인다.
2. 직렬화의 캡슐화의 이점
   1. 직렬화된 객체는 외부로부터 데이터를 캡술화하고 보호하는 데 도움이 된다. → 보안 기술 적용하기 좋다.
   2. 객체를 직렬화함으로써 플랫폼간의 호환성을 높일 수 있습니다.
3. 엔티티를 프레젠테이션 레이어에 노출시키지 않을 수 있다.

 

위의 DTO 이점 중 3번에 대해서는 알고 있었지만, 1번과 2번 장점은 이번에 공부하며 처음 알게되었습니다.

 

 

 

다음 고민은 "DTO를 불변객체로 만들어야할까? "입니다

 

기존에 DTO에 대해 가지고 있던 생각은 굳이 DTO를 불변 객체로 만들 필요가 있을 까?? 였다.

이유는 협업 시 다른 개발자가 실수로 DTO를 건들 지 않는 이상 DTO가 수정될 일이 없다고 생각했기 때문이다.

 

결론부터 말하자면, 이 생각은 아주 배부른 생각이었다.

DTO를 불변 객체로 만들어야 하는 이유는 위와 같이 생각했던 가능성을 애초에 차단하기 위해서이다.

따라서,  DTO를 불변 객체로 만든다면 멀티 스레드 환경에서 특정 스레드의 데이터가 변경될 우려 없이 DTO를 잘 사용할 수 있다.

 

한 가지 이점이 더 있는데, 불변 객체는 객체 복사시 객체 전체가 아니라 참조를 복사하기 때문에 메모리가 절감되어 성능이 좋다.

 

결론: DTO를 불변 객체로 만들자!! -> Record를 사용하면 더 좋고!!

 

 

 

마지막으로, DTO의 제공 단위에 대한 고민입니다.

 

1. 모든 응답 케이스에 대응하게끔 DTO를 만든다.
2. 비슷한 응답 케이스들은 공통 응답 DTO를 만들어 사용한다.

 

DTO의 제공단위에는 위와 같이 2가지가 있습니다.

1번의 경우에는 코드가 중복되는 것처럼 보이더라도, 명확하게 설계할 수 있습니다. 또한, 서비스가 확장되고 요구사항이 변경되더라도 쉽게 대응할 수 있다. 하지만, DTO가 너무 많을 경우에 유지보수가 어렵고, 네이밍 하기도 난해합니다.

2번의 경우에는 좋아보이지만 아래와 같은 의문이 생길 것입니다.

그러면, 공통 응답 DTO는 어떤 기준으로 만들 것인가

공통 응답 DTO를 만드는 데 저만의 기준은 아래와 같습니다.

- 공통 응답 DTO로 만들어도 될만큼 변경 가능성이 적은 것인가??

 

제가 내린 결론은 서비스의 확장성을 고려하여 "모든 응답 케이스에 대응하게끔 DTO를 만들자!!" 입니다!


따라서, 필연적으로 DTO가 많아질 것이기 때문에 DTO의 변수명을 짓는 제 나름의 결론을 내려봤습니다!


1. 요청은 ~Request ~ DTO, 응답은 ~Response ~ DTO라고 팀끼리 미리 협의를 해두고, 요청과 응답이 아닌 DTO는 ~DTO라고 끝나도록 이름을 짓는다.
    1. 첫 번째 ~는 상위 디렉토리의 이름을 사용하고, 두번째 ~ 는 메서드 명을 활용한다.
2. DTO를 만들 때 내부 클래스를 적극 활용하라!

 

 

지금까지 DTO에 대해서 생각해 본 것을 정리하는 포스팅이었습니다