[ Concept ] DTO 타입이란?

참고 사이트

• 냠냠맨(React와 Typescript를 좋아하는 개발자)님의 티스토리

• hudi님의 개인 블로그

 

사이드 프로젝트를 진행하면서 DTO를 정의해야하는 일이 생겼다.

DTO에 대해 개념이 부족하여 정리해보았다.

📦DTO

DTO (Data Transfer Object)는 계층간 데이터 전송을 위해 도메인 모델 대신 사용되는 객체이다.

이때, 계층이란 Presentation(View, Controller), Business(Service), Persistence(DAO, Repository)등을 의미한다.

주로 백엔드 API와 데이터를 주고 받을 때 사용하는 객체 구조를 정의한 타입이며 자료구조체라고도 불린다.

 

• 목적: 데이터의 구조를 명확히 정의하고 타입 안정성을 보장

• 사용 위치: API 요청(request)이나 응답(response)시에 사용

 

DTO는 메서드 호출을 줄이는 것을 주 목적으로한다.

DTO는 순수하게 데이터를 저장하고 데이터에 대한 getter, setter만 가져야한다.

DTO는 어떠한 비지니스 로직을 가져서는 안된다.

DTO는 저장, 검색, *직렬화, 역직렬화 로직만을 가져야한다.

 

*직렬화: DTO를 Byte, JSON, XML 등의 형태로 변환하는 것을 의미한다. 역직렬화는 그 반대를 의미한다.

 

🤔 왜 DTO를 써야할까?

DTO대신 도메인 모델을 계층간 전달에 사용하면, UI 계층에서 도메인 모델의 메소들르 호출하거나 상태를 변경 시킬 수 있다. 또한 UI화면마다 사용하는 도메인 모델의 정보는 상이하다. 하지만, 도메인 모델은 UI에 필요하지 않은 정보까지 가지고 있다. 즉, 도메인 모델을 캡슐화하여 보호할 수 있다.

 

또한 도메인 모델을 계층간 전송하면 모델과 뷰를 강하게 결합할 수 있다. 뷰의 요구사항 변화로 도메인 코드를 변경해야 할 일이 생기는것은 좋지 않다. DTO를 사용하면 이 결합을 느슨하게 만들 수 있다.

 

 

1. 데이터 캡슐화

• 도메인 모델의 내부 구조를 숨김

• 클라이언트에게 필요한 데이터만 노출

 

2. API 버전 관리

• 도메인 모델이 변경되어도 DTO는 유지 가능

• API 호환성을 유지하면서 내부 구현을 변경 가능

 

3. 성능 최적화

• 필요한 데이터만 전송하여 네트워크 부하 감소

• 불필요한 데이터 전송 방지

 

4. 보안 강화

• 민감한 정보는 DTO에서 제외 가능

• 권한에 따른 다른 DTO 사용 가능

 

5. 유연성 향상

• 클라이언트 요구사항에 맞게 DTO 구조 조정 가능

• 다양한 클라이언트에 맞는 다양한 DTO 제공 가능

 

6. 명확한 타입 보장

7. 코드 자동완성 및 타입 체크로 개발 효율 증가

8. 백엔드 인터페이스 동기화

 

 

🥊 도메인 모델과 비교해보기

// 도메인 모델
class User {
  id: number;
  username: string;
  password: string; // 민감한 정보
  email: string;
  role: string;
  createdAt: Date;
  updatedAt: Date;
  
  // 비즈니스 로직
  changePassword(newPassword: string) { ... }
  validateEmail() { ... }
}

// DTO (클라이언트에게 전송)
class UserDTO {
  id: number;
  username: string;
  email: string;
  role: string;
  // password는 제외 (보안)
  // 비즈니스 로직 메서드는 제외
}

 

필요한 값만 쏙쏙 뽑아 사용 가능.

🤔DTO는 어떤 계층까지 사용되어야 할까?

일단, DTO 영속 계층(Persistence Layer)까지 도달하는 것은 공통적으로 지양하는 모양이다.

그렇다면, Controller와 Service 레이어 둘 중 DTO는 어디서 변환되어야 할까?

 

마틴파울러는 Service Layer란 어플리케이션의 비즈니스 로직. 즉, 도메인을 보호하는 레이어라고 말한다.

즉, 이 정의를 명확히 지키기 위하여 Presentation Layer에 도메인을 노출해서는 안된다. 따라서 이러한 관점으로 도메인은 서비스 레이어에서 DTO로 변환되어 컨트롤러로 전달되어야한다.

 

🧐 레이어 구성 알아보

1. 프레젠테이션 레이어 (Presentation Layer)

- 역할: 사용자에 인터페이스와 상호작용, 요청/응답 처리

- 구성: 컨트롤러(Controller), 뷰(View), API 엔드포인트

특징

- 사용자 요청을 받아 서비스 레이어로 전달

- 서비스 레이어에서 반환된 DTO를 클라이언트에게 전달

- 도메인 모델을 직접 사용하지 않음

 

2. 서비스 레이어 (Service Layer)

- 역할: 비즈니스 로직 처리, 도메인 보호

- 구성: 서비스 클래스들

특징

- 도메인 모델을 사용하여 비즈니스 로직 구현

- 도메인 모델을 DTO로 변환하여 프레젠테이션 레이어에 전달

- 트랜잭션 관리, 권한 검증 등 어플리케이션 서비스 제공

 

3. 도메인 레이어 (Domain Layer)

- 역할: 핵심 비즈니스 로직과 규칙 정의

- 구성: 도메인 모델, 도메인 서비스, 레포지토리 인터페이스

특징

- 비즈니스 규칙과 로직을 포함하는 도메인 모델 정의

- 다른 계층에 의존하지 않는 독립적인 계층

- 도메인 주도 설계(DDD)의 핵심

 

4. 인프라스트럭쳐 레이어 (Infrastructure Layer)

- 역할: 기술적 세부사항 구현

- 구성: 레포지토리 구현체, 데이터베이스 접근, 외부 API 연동

특징

- 도메인 레이어의 인터페이스를 구현

- 데이터베이스, 외부 서비스와의 통신 담당

- 기술적 세부사항을 캡슐화