Presentation - Business DTO를 분리시켜라

 

 

Layered Architecture 개발 중이라면
Presentation - Business Layer 의
Request DTO의 분리를 고려하라.

 

공통의 Request DTO 사용시 문제점

Controller, Service 모두 같은 RequestDTO 를 쓰면 다음과 같은 문제가 발생한다.

 

1. Controller 의 Validation annotation 을 Service 가 그대로 달고간다.

2. DTO에 의해 Controller <-> Business Layer 간 의존성이 생긴다.

=> Controller 및 Request DTO 추가 또는 변경시 Service Layer 가 영향을 받는다.

 

 

다이어그램으로 도식화하여 표현해보겠다.

만약, API Spec 이 확장된다면 어떻게 될까?

API 확장과 더불어 Controller 추가시 RequestDTO 의존성에 의해 변경이 까다롭다.

 

DTO 분리 예시

Business Layer 에 쓸 DTO를 별도로 만들어라.

 

추가된 새로운 DTO에서 `ProductServiceRequestDTO` 로의 변환 로직은 필요하다.

그러나 동일 DTO를 쓰는 설계에 비하면 디커플링된 형태로 볼 수 있다.

Controller 또는 Business 에서 직접 서로 다른 계층에서 쓰는 DTO를 직접 의존하지 않게되기 때문이다.

 

 

 

그럼 무조건 Service DTO 를 별도로 다 만들어야하나?

소프트웨어 개발에 "무조건"은 없다.

단일 Controller로 API 스팩이 변경될 가능성이 매우 낮은 서비스라면 처음부터 무지성으로 DTO를 다 분리시켜 만들어 두는 것은 오버 엔지니어링이 될 수 있다.

 

 

YAGNI 원칙

You Aren't Going to Need It
그것은 필요없어진다.

"아마 필요해지겠지", "필요해질지도 몰라" 같은 식으로 코드를 휘갈겨선 안된다.

확장성을 고려한 설계도, 실제로 '사용해야' 가치가 생긴다.

사용자가 확보되고, 비즈니스 운영이 잘되어 Controller, API Spec의 확장이 필요해져야, 확장성을 고려한 설계가 의미가 있다. 그렇지 못하면 오히려 복잡성만 높아진 설계가된다.

 

오버엔지니어링은 '미래에 발생할 수도 있는 문제'를 지금의 시간과 노력을 갈아서 방지하는 것이다.

오버엔지니어링 하지마라