controller 에서 dto 그대로 전달하기 vs 파라미터로 나누어 전달하기

DTO 전달하는 방식

1. 서비스 확장성이 높음
   • 새로운 필드가 추가될 경우, Service의 메서드 시그니처를 변경하지 않고 DTO만 수정하면 된다. 
2. 의미 전달이 명확함
   • DTO 자체가 하나의 도메인 개념을 가지므로, 어떤 요청인지 쉽게 이해 가능하다.
3. 서비스 인터페이스가 명확함
   • createUser(UserRequestDto requestDto)처럼 도메인 중심적인 메서드 시그니처를 유지할 수 있다.

하지만 반대로 동일한 함수를 다른 곳에서도 사용하고 싶을 때 dto 를 만들어서 전달하는 과정이 추가될 수도 있다. 

 

 

파라미터를 전달하는 방식

1.  DTO 와 독립적: dto가 변경되어도 service 레이어가 변경될 필요는 없다. 
2. dto 는 controller 의 요청을 표현하는 역할, service 레이어는 비즈니스 레이어를 수행하는 역할을 명확하게 나누어서 표현할 수 있다. 
3. 굳이 dto를 만들지 않아도 되기 때문에 service 에 대한 테스트를 만들기가 쉽다. 

대신, dto 의 필드가 추가된다면 메서드를 함께 수정해야한다는 점, 필드가 많다면 메서드를 보기 복잡해질 수 있다는 점을 고려해야한다. 

 

 

결론적으로 어느 것이 맞다고 볼 수는 없지만, 지금까지의 경험상으로는 

api 한 곳에서 쓰이는 service 라고 하더라도, api가 많고 이미 requestDto가 많은 상황이라면, dto내부의 필드를 모두 기억하기 어렵기 때문에 파라미터를 나누어서 요청하는 것이 service 레이어에서 어떤 데이터를 갖고 로직이 수행되는지 알 수 있어서 가독성이 높아진다는 장점이 있었다. 

 

따라서 frontend와 주고받는 데이터의 구조가 자주 변하지 않는다면 나는 파라미터를 보여주는 방식이 더 괜찮지 않을까,하는 의견을 갖고 있다. 

 

단순히 내 의견만으로 코드를 작성하고 싶지는 않고 더 생각해볼 점이 있다면 다음과 같다. (사실 내가 보고 있는 코드는 이미 dto 방식이 더 많기 때문에)

 

- 파라미터가 많다면 가독성이 저하된다.  단순히 가독성뿐만 아니라, 잘못해서 파라미터의 순서가 바뀔 경우 디버깅이 어려울 수 있다. (경험담..)

- DTO는 도메인 개념과 1:1로 매핑될 수 있으므로, DDD 관점에서는 DTO 사용이 권장될 가능성이 높다.

- dto 방식과 파라미터 방식이 혼용된다면, 어떤 컨벤션을 갖고 전달하는 것이 좋을까? 즉 어떻게 일관성을 유지할 수 있을까?

-  메서드 내에서 어떤 데이터를 다루고 있는지 쉽게 파악할 수 있는 구조를 유지하려면 어떤 기준을 세우는 게 좋을까?

 

현재 시점으로는 간단히 이런 기준을 만들 수 있을 것 같다. 

 

1. 파라미터의 개수가 5개 이상이 되는 메서드는 지양하는 게 좋을 것 같다. 

2. 특정 api에서만 사용하는 service라면 dto 를 사용하는 부분을 더 건들 필요는 없을 것 같다. 

3. controller 에서만이 아니라 service layer 중 더 안쪽 service 내에서도 dto 를  인자로 보낸다면, 이 부분은 실제로 사용되는 파라미터만 전달하도록 수정하는 것이 좋을 것 같다. 

4. 데이터가 많아질 수록 dto 를 매번 전달하는 것이 성능에도 영향을 미칠 수 있다. (하지만 현재 서비스에서 이런 부분까지 고려할 필요는 없을 수도 있다. )

5. 테스트가 반드시 필요한 service의 경우 파라미터 방식을 좀 더 고려하자.

6. 일단 개발자가 dto 내부 필드를 한눈에 예측하기 어렵고 필드 개수가 많은 상황에서는 파라미터 방식을 좀 더 고려하자.