포스트

2021-05-14-TIL

2021-05-14-TIL

Request and Response DTO naming convention

컨트롤러가 주고받는 DTO의 이름을 어떻게 짓고, 요청과 응답에 같은 DTO를 재사용해도 되는지 찾아본 자료다.

먼저 DTO를 엔티티와 분리하는 이유부터다. 우아한테크코스의 DTO vs Entity 글(지금은 주소가 바뀌어 열리지 않는다)이 이 주제를 다룬다. 엔티티를 그대로 요청과 응답에 쓰면 화면이나 API 스펙이 바뀔 때마다 도메인 모델이 함께 흔들리고, 응답에 노출하면 안 되는 필드까지 나갈 수 있다. 그래서 계층 사이의 데이터 전달은 DTO가 맡고, 엔티티는 도메인 규칙에 집중하게 한다.

이름은 링크된 논의들에서 대체로 다음 관례가 많이 쓰인다.

  • 용도를 접미사로 붙인다: CreateQuestionRequest, QuestionResponse처럼 요청은 Request, 응답은 Response로 끝낸다. 입력과 출력이 이름만 보고 구분된다.
  • 엔드포인트마다 별도 DTO를 둔다: 생성 요청에는 ID가 없고 수정 요청에는 일부 필드만 필요하듯, 같은 리소스라도 요청마다 필요한 필드와 검증 규칙이 다르다. 하나의 DTO를 여러 용도로 재사용하면 어떤 필드가 언제 채워지는지 알기 어려워진다.
  • 반대로 DTO가 지나치게 늘어나는 비용도 있다. Stack Overflow 논의에서는 명시성과 클래스 수 사이의 균형을 두고 의견이 갈리며, 필드 구성이 완전히 같을 때만 재사용하자는 절충안도 나온다.
1
2
3
4
5
6
7
public record CreateQuestionRequest(String title, String contents) { }

public record QuestionResponse(Long id, String title, String writer) {
    public static QuestionResponse from(Question question) {
        return new QuestionResponse(question.getId(), question.getTitle(), question.getWriter().getName());
    }
}

응답 DTO에 엔티티를 받아 변환하는 정적 팩토리(from)를 두면 변환 코드가 한곳에 모인다.

  • https://forums.servicestack.net/t/request-and-response-dto-naming-convention/6142
  • https://woowacourse.github.io/javable/post/2020-08-31-dto-vs-entity/
  • https://groups.google.com/g/agatha-rrsl/c/5Zunzrb0ryg?pli=1
  • https://medium.com/the-resonant-web/spring-boot-2-0-project-structure-and-best-practices-part-2-7137bdcba7d3
  • https://stackoverflow.com/questions/63184635/is-there-any-naming-convention-for-in-and-out-dto
  • https://stackoverflow.com/questions/44349199/reusing-dto-for-various-request-response-types-vs-explicitness-of-what-is-requir

서버 설계 by Honux

서버 설계를 다룬 Notion 문서 링크를 남겨 두었다.

  • https://www.notion.so/22b5d93081cb458e91057c85a931e6de

책 추천

  • http://www.yes24.com/Product/Goods/91236635?pid=123487&cosemkid=go15954914023734968&gclid=CjwKCAjw-e2EBhAhEiwAJI5jg3I_0jbO2ZRL4-pObuyUsSdaLWVzag09oTsnR8cJyZ5YUAjnEH7z7RoCemMQAvD_BwE
참고한 자료외부 출처 1

외부 출처

이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

댓글

아직 댓글이 없습니다