DTO 란?

클라이언트 - 서버 프로젝트에서 데이터는 각 단에서 종종 다르게 설계 된다. 이러한 방법은 데이터를 데이터베이스 친화적으로 저장할 수 있게함과 동시에 유저 친화적으로 정보를 제공할 수 있게 한다. 서버는 이 두 데이터 포맷을 변환할 수 있는 방법을 가지고 있어야 한다.
DTO가 그런 역할을 하게 된다.

DTO는 Presentation 계층의 표현 방식을 사용하여 데이터를 저장하는 value object 이다.
DTO는 서버에서 수신한 DTO(request)와 서버에서 반환한 DTO(response)로 구분된다. Spring이 자동으로 이들을 직렬화/역직렬화 해준다.

클라이언트-서버 프로젝트에서 한 번의 호출은 매우 비싸다. 따라서 각 호출의 횟수를 줄여야 한다. 다시 말해 각각의 호출 마다 더 많은 데이터를 전달받아야 한다는 소리이다. 하지만 이는 단일 값만 반환하는 자바에서는 힘든 일이 될 수도 있다.

DTO를 사용하면 호출에 대한 모든 데이터를 보유할 수 있어 이 문제에 대한 해결책이된다.

좋은 DTO

DTO는 의무적인 방안이 아니다. DTO는 패턴의 일종이며, DTO없이도 동작 자체에는 문제가 없다.

• 만약 두 계층에서 데이터를 같은 방식으로 표현한다면 엔티티를 DTO로 사용하면 된다.

DTO는 Presentation 계층과 Domain 계층을 분리해줌과 동시에 유지보수 비용을 줄여준다는 장점이 있다. 하지만 모든 DTO가 좋은 DTO는 아니다.

public class CreateProductRequest {
    private String name;
    private Double price;
}

public class ProductResponse {
    private Long id;
    private String name;
    private Double price;
}

@PostMapping("/products")
public ResponseEntity<ProductResponse> createProduct(
    @RequestBody CreateProductRequest request
) { /*...*/ }

한 엔드포인트의 parameter에 대한 지식은 모든 관련 엔드포인트에서 동일한 이름을 가진 parameter에 적용되어야 한다. 예를 들어 위의 코드에서 price 요청에 VAT가 포함된 경우 응답 price에도 VAT가 포함되어야 한다. 일관된 API는 엔드포인트 간의 차이로 인해 발생할 수 있는 버그를 방지하게 된다.

상용구를 최소화 하고, 작성하는 데 오류가 없어야 한다. DTO를 작성하는데 있어서 실수가 발생하기 쉽다면, 유지보수하기 어려워진다.
또한 읽기 쉬워야 한다. 다른 클래스로부터 온 DTO여도 한 눈에 그 구조를 알 수 있도록 보기 좋게 작성해야 한다.