DTO 관리에 대한 고민과 리펙토링

🤔 1. 고민..

현재 나는 창업 프로젝트에서 혼자 백엔드 개발을 맡아 진행하고 있다. 

 

대학생이니 당연히 사수도 없고, 같이 고민하고 토론할 백엔드 팀원도 없으니 내가 결정한 모든 것이 그대로 프로젝트에 반영되었다. 나의 잘못된 판단, 습관 들로 프로젝트가 망가지지 않도록 하기 위해 끊임없이 되돌아보고 조언을 구하며 진행하고 있다. 

 

현재 프로젝트는 큰 틀로 domain, global 를 나눴고, 도메인 별로 entity, dto등 생성하고 있었다. 

하지만 프로젝트 규모가 커짐에 따라 dto관리를 하기가 너무 힘들었다. 당장 몇 주 전에 개발했던 코드를 딱 봤을 때 무슨 역할을 하는 클래스인지 바로 알아차리기 힘들었다. 나름 코드에 신경을 많이 써서 개발 하는 스타일인데 규모가 커지니 어지러웠다. 

 

아래는 프로젝트 디렉토리 중 일부를 캡쳐한 사진이다.

 

dtos 폴더를 보면 offer, project 등 domain 폴더가 또 들어있다. 

만약 offer 도메인과 관련된 반환 데이터에 jobPost 데이터가 포함되야 한다면 offer 디렉토리에 dto를 생성해서 사용했었다. 

나름 알아보기 쉽자고 이렇게 했는데 좋은 방식이 아니란 생각이 들었다. 

 

역시 다른 많은 개발자 분들이 이미 이런 고민을 했고, 다양한 방법으로 해결하고 있었다. 

 

 

그 중 Inner Class로 리펙터링을 진행할 예정이다. 

 

사실 예전 프로젝트에도 이걸 도입할까 하다가 [outer_class].[inner_class]  처럼 접근해야 해서 도입하지 않았는데, 그땐 프로젝트 규모가 작아서 그런 생각을 했던 것 같다.. 

 

 

물론 dto를 사용할 때 이전보다 길어지는 건 맞지만 모든 해결책엔 trade-off 가 있는 법이니..^^

No Silver Bullet (은총활은 없다)

 

 

 

 

 

 

2. 개선 방법

DTO 관리 방법을 찾아보다보니 Inner Class를 활용하는 방법이 있어서 프로젝트에 도입했다.

 

 

Inner Class를 활용하면 여러개의 DTO 하나의 클래스에서 깔끔하게 관리할 수 있다. 수정사항이 생기면 여러 곳을 돌아다니면서 수정할 필요가 없고 위에서 내가 느꼈던 문제점을 해결할 수 있었다.

 

 

아래는 Inner Class 를 사용하여 계선하는 코드의 예시이다. 

 

2.1 개선 전

 

- 메인 반환 DTO

public class ProductDto {

    private final SellerDto seller;
    private final CategoryDto category;
    private final AddressDto address;
    private final String title;
    private final String contents;
    
    }

 

 

- 필드에 들어갈 DTO

public class SellerDto {

    // 생략...
    
    }
    
public class CategoryDto {

    // 생략...
    
    }
    
public class AddressDto {

    // 생략...
    
    }

 

나의 프로젝트 구조였다면 SellerDto는 Seller 디렉토리에, CategoryDto는 CategoryDto에.. 어지럽다..

이걸 InnerClass로 관리하면 아래와 같이 사용할 수 있다. 

 

 

2.2 개선 후

public class ProductDto {

    private final String title;
    private final String contents;
    private final SellerDto seller;
    private final CategoryDto category;
    private final AddressDto address;

    
    private static class SellerDto {
	// 생략
    }

    private static class CategoryDto {
	// 생략
    }

    private static class AddressDto {
	// 생략
    }
}

 

확실히 어떤 Dto를 보고 어디에 사용하는 Dto인지 알아채기 쉬울 것 같다.

 

 

아래는 실제로 내 코드를 어떻게 리펙터링 했는지 일부 과정을 담았다. 

 

아래 DTO는 인력 관리 기능에서 반환되는 DTO이다. 

 

 

dto명이 정말.. 별로다. 처음부터 저렇게 지저분하진 않았다. 어떤 dto를 봤을 때 어디서 사용하는 dto인지 클래스명만 보고도 알 수 있게 하고싶어 저런식으로 작성했는데 너무 많아지다보니 매번 다른 이름으로 작성하는게 힘들어지고 길어졌다. 

 

MemberResponseForApplyHistory 클래스는 member 디렉토리에 들어가있었고, 이것도 member 디렉토리에서 해당 dto를 봤을 때 어디에 사용하는건지 알 수 있게 하려고 저런식으로 지었다.

 

 

이걸 inner class로 사용하면서 아래와 같이 변경할 수 있었다. 

member 디렉토리에 있던 dto는 삭제하고 static class로 수정해줬다. 

 

 

@Getter
@Builder
public class ApplyManageResponse {
    /**
     * 인력 관리: 대기 중인 인부 조회
     * 인력 관리: 확정 된 인부 조회
     */
    private Long applyId;
    private MemberResponse memberResponse;

    public static ApplyManageResponse from(Apply apply) {
        return ApplyManageResponse.builder()
                .applyId(apply.getId())
                .memberResponse(MemberResponse.from(apply.getMember()))
                .build();
    }


    @Builder
    public static class MemberResponse {
        private Long memberId;
        private String workerName; // 노동자 이름
        private String phone; // 휴대폰 번호
        private Integer age; // 나이
        private Gender gender; // 성별
        private String nationality; // 국적
        private Integer workTimes; // 출역 횟수
        private Float participationRate; // 참여율

        public static MemberResponse from(Member member) {
            // 나이 계산
            int age = AgeTransfer.getAgeByBirth(member.getWorkerInfo().getBrith());

            // 출역 횟수, 참여율
            List<History> workHistory = member.getHistoryList().stream()
                    .filter(history -> history.getEndStatus() == WorkStatus.FINISH_WORK)
                    .collect(Collectors.toList());
            int workTimes = workHistory.size();
            float participationRate = (float) workTimes / (float) member.getHistoryList().size();

            // 출역 내역이 없을 경우 -1
            if (workTimes == 0) {
                participationRate = -1;
            }

            return MemberResponse.builder()
                    .memberId(member.getId())
                    .workerName(member.getWorkerInfo().getWorkerName())
                    .phone(member.getPhone())
                    .age(age)
                    .gender(member.getWorkerInfo().getGender())
                    .nationality(member.getWorkerInfo().getNationality())
                    .workTimes(workTimes)
                    .participationRate(participationRate)
                    .build();
        }
    }
}

 

위 코드에선 하나의 dto만 inner로 담았지만 4~5개의 dto를 랩핑하는 dto도 존재했고 Inner Class로 깔끔하게 처리할 수 있었다. 

 

 

 

 

 

 

3. 결론

수정할 내용들이 많아 수정을 완료한건 아니지만 확실한건 새로운 백엔드 개발자가 합류하게 됐을 때 코드를 이해하기 쉽겠다 라는 생각이 들었다. 

 

 

이 방식의 한가지 아쉬운 점이 있다면 여러 곳에서 똑같은 형태로 사용하는 DTO가 Inner Class로 존재한다면 재사용하기 애매한 감이 있다.

이럴 경우 나는 Inner Class로 두지 않고 그냥 공용 DTO로 분리해서 사용하고 있다.

 

 

더 좋은 방법이 있다면 댓글로 남겨주세요!