DTO를 깔끔하게 정리하는 방법이 없을까?

 

 

 

---

 

프로젝트를 하다보면 DTO가 너무 많아진다.
많은 DTO를 깔끔하게 정리하는 방법이 무엇일까?

 

 

---

 

 

 

 

DTO가 많아지면?

 

--

우선 DTO의 이름을 짓는 부분에서 어려움이 생긴다.

이름을 지을 때 비슷한 이름들로 짓게 되기도 할 것이고 DTO가 많아질 수록 DTO를 구분하기 어려워지고 난잡해진다.

그리고 코드의 가독성과 유지보수성에 대해서도 문제가 발생할 수 있다.

--

 

 

 

 

패키지(폴더)로 구조화하기

 

--

관련된 DTO끼리 패키지에 따라 그룹화로 하는 방법이다.

 

order에 관련된 DTO는

"com.example.application.dto.order" 패키지 안에 넣고

 

item에 관련된 DTO는

"com.example.application.dto.item" 패키지 안에 넣어서

 

각자 관련된 DTO끼리 묶어서 관리하는 방법이다.

 

해당 방법은 DTO를 찾기에 보다 수월해서 유지보수하기에는 보다 좋을 것이다.

다만 DTO의 개수는 그대로인 단점이 있다.

--

 

 

 

 

DTO 재사용하기

 

--

DTO의 중복을 최소화하고 하나의 DTO로 여러 곳에서 사용하는 방법이다.

또는 공통 필드를 가진 DTO를 만들고 해당 공통 필드가 필요한 곳에서 공통 DTO를 상속받아서 확장하여 사용한다.

 

해당 방법은 중복된 코드의 수를 줄이고, 유지보수도 좋아질 것이다.

--

 

 

 

 

프로젝트를 모듈화하기

 

--

프로젝트 자체를 역할별 각 모듈로 나누어서 독립적으로 개발, 배포할 수 있도록 한다.

 

결제에 관련된 동작만 하는 프로젝트,

상품에 관련된 동작만 하는 프로젝트,

회원에 관련된 동작만 하는 프로젝트 등의 모듈로 나누어 개발한다.

 

프로젝트의 유지보수 자체를 향상시키게 된다.

--

 

 

 

 

inner class로 사용하기

 

--

패키지로 구조화하는 느낌과 비슷하다.

다만 패키지 대신에 class를 사용하는 것이다.

 

order에 관련된 DTO는 

order 클래스 안에 inner class로 작성하고

 

item에 관련된 DTO는

item 클래스 안에 inner class로 작성한다.

 

예시

public class OrderDto {

    // 주문 목록 조회 응답 (페이지)
    @AllArgsConstructor
    @NoArgsConstructor
    @Getter
    @Setter
    public static class OrderPageResponse{
        private List<OrderResponse> orderList;
        private int totalPage;
        private int nowPage;
    }
    
    // 주문 상태 변경 요청
    @AllArgsConstructor
    @NoArgsConstructor
    @Getter
    @Setter
    public static class AdminOrderStatus{
        private Long orderId;
        private String status;
    }
}

--