계층 사이에서 데이터를 나르되 비즈니스 로직은 갖지 않는 DTO의 역할을, 상태와 행동을 함께 지니는 도메인 객체와 대비해 설명한다. 도메인을 API에 직접 노출할 때 생기는 문제를 출발점으로, DTO를 어디서 어떻게 나누고 변환할지의 실무 선택으로 나아간다.
핵심 포인트- DTO는 데이터 전달에 집중하고 비즈니스 규칙을 수행하지 않는 반면, 도메인 객체는 문제 영역의 상태·행동을 표현하며 엔티티(식별자 중심)와 값 객체(값 자체가 의미)로 나뉨
- 도메인을 요청·응답에 그대로 쓰면 불필요한 필드 노출, 내부 구조 변경의 API 계약 전파, 화면별 형태 차이, 검증·표현 책임 혼입이 생기므로 DTO로 경계를 만들어 캡슐화·변경 독립성 확보
- Controller가 요청 DTO로 받아 형식·경계 조건을 검증하고, Service·Repository가 도메인 모델로 규칙을 처리한 뒤 응답 DTO로 필요한 모양만 반환 — 단순·단일 진입점이면 요청 DTO를 Service까지 넘기는 것도 실용적이나, 매장/배달 주문처럼 여러 어댑터가 다른 입력을 주면 서비스 전용 DTO로 변환해 프레임워크 결합·nullable 확산을 줄임
- 변환은 Service·정적 팩터리·별도 mapper 중 '어느 계층 변경을 격리할지'로 위치 결정, Java record는 불변 전달 보일러플레이트를 줄이고 class·명시적 생성자는 생성·표현을 세밀히 통제
왜 읽나'왜 굳이 DTO를 또 만드나' 싶은 백엔드 개발자에게, 계층 분리의 이유와 요청/서비스 DTO 분리·record 선택 같은 실무 판단 기준을 정리해주는 톡.