Model이 DTO의 존재를 모르게 하라? Model과 DTO

Model과 DTO에 대한 의문점들

 

• DTO와 Model을 왜 분리해야하는가?
• Model이 DTO의 존재를 모르게 하라?
• Model→ DTO에 대한 파싱은 어느 레이어에서 수행되어야 하는가?

 

DTO와 Model을 왜 분리해야할까?

 

가장 중요한 이유는 DB의 민감한 정보를 Response하지 않기 위함일 것이다.

 

다른 시각으로 협업을 생각해보자 (멘토님은 FE와 BE의 의존성을 분리한다. 라는 말씀을 하셨다)

 

만약 FE쪽에서 REQUSET를 위한 프로퍼티명을 하나 변경했다고 가정하자.

DTO가 없는 환경이라면 BE쪽에서는 Model의 변수명을 변경해야 할 것이고 연쇄적으로 해당 변수와 연관된 비즈니스 로직의 메서드명, 내부 동작에서의 변수명을 변경해야 할 것이다.

 

당장 생각나는 것만 해도 모델의 변수명, 서비스 레이어의 메서드명과 지역변수명, JPA를 사용한다면 Repository의 메서드명,, 변경할 게 이렇게 많다.

 

고작 REQUEST를 위한 프로퍼티명을 변경했을 뿐인데, 이를 처리하기 위한 비용이 너무 커지게 된다.

 

 

 

자 그럼 DTO가 존재한다면 어떨까?

 

DTO의 변수명만 변경하면 된다. 기껏해봐야 DTO → Model 혹은 반대로 파싱되는 부분의 변수명만 수정하면 된다.

FE와 BE사이의 강한 의존성을 DTO를 통해 끊어버리는 것이다.

 

 

자 그럼 다음 질문도 자연스럽게 해결이 될 것이다.

 

Model이 DTO의 존재를 모르게 하라?

 

아래와 같이 Stadium이라는 모델 내부에 DTO를 생성하는 팩토리 메서드가 존재한다고 가정하자.

@Getter
@Builder
public class Stadium {

    private Long id;
    private String name;

    public static Stadium from(RequestDTO request) {
        return Stadium.builder()
                .id(request.getId())
                .name(request.getName())
                .build();
    }
}

위의 상황과 같이 REQUEST의 프로퍼티명이 변경되어야 하는 상황이 발생한다면?

 

DTO가 존재하는 상황인데도 굳이굳이 Model 내부의 메서드를 수정해야하는 상황이 발생한다.

그렇기 때문에 Model은 DTO의 존재를 모르게 하는 것이 좋다고 생각한다.

 

번외로 Model이 DTO를 의존하게 되면 DIP에 위배되는 느낌이다.

“변하기 쉬운 것에 의존하지 말라”

 

 

Model ↔ DTO에 대한 파싱은 어느 레이어에서 수행되어야 하는가?

보편적인 Controller - Service - Repository 구조에서는 Service에서 수행되는 것이 적합하다고 생각한다.

DTO의 사용 범위에 대하여