DTO 를 사용해야 하는 이유

1. 필요한 데이터만을 응답으로 줄 수 있다.

• 클라이언트로 넘겨줘야 할 정보는 API 마다 상이하다.
• Entity 자체를 클라이언트에 대한 응답으로 넘기는 것은 불필요한 데이터를 포함할 수 있으며, 혹시 모를 민감 정보 노출 등의 문제를 일으킬 수 있다.

2. Entity 구현을 캡슐화하여 보호할 수 있다.

• DTO 가 없다면 클라이언트의 요청과 Entity Model 이 강하게 결합되어 클라이언트에서의 요구사항 변화가 Entity 에 영향을 끼치기 쉽다.
• Entity 는 도메인의 핵심 로직, 속성을 갖고 있으며, 실제 DB 테이블에 대응되는 클래스이므로 함부로 변경되지 않도록 보호되어야 한다.

3. Validation 코드와 Entity 속성 코드를 분리할 수 있다.

• Entity class 에는 @Column, @Embedded, @OneToMany 등 모델링을 위한 어노테이션들이 사용된다.
• 이 Entity 영역에 @NotNull, @Min, @Lenth 등 형식적 validation 에 대한 코드가 함께 들어간다면, Entity class 는 모델링과 검증을 함께 담당하며 class 가 복잡해지게 된다.

 

< 추가로 고민할 것 >

Martin Fowler, Patterns of Enterprise Application Architecture p.401

baeldung, The DTO Pattern

DTO 를 사용해야 하는 이유에 대해서는 추상적으로만 기억하고 있어서 기억나는 것을 글로 남겨보았다. 참고를 위해 여러 글을 찾던 중 위와 같은 이미지를 발견했고, 이어서 바로 다음으로 'DTO 를 어떻게 변환해야 하는지' 에 대해 정리해 보면 좋을 것 같다.

1. [링크] DTO 를 사용해야 하는 이유
2. [링크] DTO 는 어떻게 구성하고, 변환해야 할까?
3. [링크] Nested Class 에 언제 static 을 붙여야 할까?

https://martinfowler.com/eaaCatalog/dataTransferObject.html

P of EAA: Data Transfer Object

https://www.baeldung.com/java-dto-pattern

The DTO Pattern (Data Transfer Object) | Baeldung