개요

미션을 진행하며 요청 객체를 DTO로, 엔티티를 응답 객체로 변환하는 부분이 존재했습니다.
하지만 이러한 부분이 다양한 메서드에서 중복되고, 필드가 많아질수록 코드가 길어짐에 따라, 개선할 방법이 없을까 고민해 보았습니다.

마침 웹 자동차 경주 미션의 리뷰어였던 조앤이 정적 팩터리 메서드를 활용하는 것이 취향이라고 소개해주셨고, 해당 방법이 떠올랐습니다.
당시엔 해당 방법의 문제점보다 편리성에 꽂혀 무작정 사용을 하였지만, 이번에는 편리성보다 문제점이 떠올랐습니다.

따라서 'DTO가 엔티티나 도메인을 알아도 되는가?' 에 대한 저만의 결론을 작성하겠습니다.

DTO가 Entity나 Domain을 알았을 때의 문제점

가장 먼저 DTO가 이 둘을 알았을 때 생기는 문제에 대해 생각해보겠습니다.

아무래도 'Domain이나 Entity의 변경이 DTO에 영향을 끼칠 수 있다. 따라서 변경 포인트가 늘어난다' 라고 생각합니다.

이때 다음과 같은 케이스가 생길 것 같아요.

A. DTO에 영향을 주는 부분이 변경된 경우
B. DTO와는 무관한 부분이 변경된 경우

DTO 존재의 목적

여기서 DTO 존재의 목적에 대해 이야기하려고 합니다.
제가 생각하는 목적은 다음과 같습니다.
도메인이나 엔티티에 존재하는 데이터 중, 클라이언트가 필요로 하는 데이터만을 하나의 계층 범위 내에서 전달하는 것이 목적이다.

따라서 위 문제점들을 다음과 같이 생각할 수 있을 것 같아요.

A. DTO에 영향을 주는 부분이 변경된 경우 -> 어차피 DTO에도 변경이 일어나야 하므로 고려하지 않아도 된다.
B. DTO와는 무관한 부분이 변경된 경우 -> DTO의 정적 팩터리 메서드 내부에서는 DTO에 포함할 값들만 getter를 활용해 가져다 쓰고 있으므로 고려하지 않아도 된다.

결론

DTO의 존재 목적을 생각해봤을 때, Domain이나 Entity의 변경을 두려워하면 안된다고 생각합니다.
그래야 DTO를 편리하고 유용하고 쉽게 사용할 수 있지 않을까요?