ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [Spring Boot] 어떻게 DTO를 재구성할까?
    스터디 & 프로젝트/Init Cloud 팀 프로젝트 2023. 3. 20. 16:19

    요즘 주변에서 들은 얘기나 하나 둘 본 자료, 강의에서 뭔가 떠오르는게 있었다.

    바로 끔찍하게 구성된 DTO를 다시 만드는 것이었다.

     

    공식적으로는 끝난 프로젝트임에도 맘에 안드는 부분을 바꾸고 싶었다.

    중복을 제거하려고 무자비하게 상속관계로만 작성한 DTO 클래스는 너무나도 유지보수가 힘들다는 것이었다.

    그래서 이 DTO를 재구성해보기로 했다.

     


    문제 상황

     

    대충 이런식으로 구성된 DTO 패키지가 있었다.

    비즈니스로직마다 각각의 DTO를 가지고 있고 부모인 UserDto부터 내려오는 구조다.

    이게 너무 난잡하다고 생각했다.

     


    어떻게 개선할까?

    우선 UserDto라는 부모 클래스는 유지하기로 했다.

     

    Dto를 보면 Profile, Retrieve 등등 회원 정보를 관리하기 위한 Dto가 있고

    Signup, Authentication 등 인증인가를 위한 Dto가 있다.

     

    여기서 유저 도메인을 UserAuth, UserDetails로 나누어서 재구성하면 어떨까? 라는 생각을 했다.

    그러면서 UserAuth, UserDetails 모두 공통적으로 가지는 필드를 UserDto라는 부모 클래스에 담고 명칭만 UserBaseDto로 바꾸어 상속하게 했다.

     


    Nested Class

    @NoArgsConstructor(access = AccessLevel.PROTECTED)
    public class UserDetailsDto {
    
    	@Getter
    	public static class Retrieve extends UserBaseDto {
    		private UserState userState;
    		private RoleType role;
    
    		public Retrieve(String username, UserState userState, RoleType role, LocalDateTime lastLogin) {
    			super(username, lastLogin);
    			this.userState = userState;
    			this.role = role;
    		}
    
    		public Retrieve(User user) {
    			super(user.getUsername(), user.getLastLogin());
    			this.userState = user.getUserState();
    			this.role = user.getRoleType();
    		}
    	}
        
        ...
    }

    사실 변경할 내용이 많지는 않았다.

    UserDetailsDto 내부에 비즈니스 로직 별로 필요한 Dto를 이너클래스로 작성했다.

     

    결과적으로는 6개의 파일로 구성된 패키지가 3개로 줄어들었다.

    이제는 어떤 명목으로 도메인을 사용할 건지 전보다 덜 헷갈리게 됐다.

     


    결론

    이 리팩토링을 하면서 Dto만 건든 것은 아니었다.

     

    패키지 구조를 정리하면서 수행한 작업 중 하나였고 미사용 메소드, @Setter로 처리된 비즈니스 로직을 생성자를 통해서 값을 할당하게 하기 등등 좀 더 가독성있고 명확한 구조를 생각해보려고 했다.

     

    그냥 이런 변경 중 작은 하나만 포스팅한건데... 그냥 하다보니 다른 맘에 안드는 부분을 계속 바꾸고 싶었다.

    이런 것들을 계속 해가면서 클린한 코드와 구조를 지향하다보면 지금은 안보이는 구조도 나중엔 더 좋게 바꿀 수 있겠지.

     

    댓글

Designed by Tistory.