ServiceRequestDto 대신 풀어서 넘기는건 어떻게 생각하시나요?

안녕하세요, psam1017 님!

음 해당 방법은 권장드리지 않습니다. ㅎㅎ
아래 AI 인턴도 비슷하게 잘 이야기해 주었는데, 우리가 만드는 시스템의 비즈니스 요구사항은 언제든 바뀔 수 있고, 그에 따라 스펙, 즉 API의 요청 파라미터나 응답 데이터도 항상 달라질 수 있습니다.
요청이나 응답을 DTO로 묶어 책임을 구분해 놓지 않는다면, 필드가 변할 때마다 Controller, Service에 있는 해당 파라미터를 전부 찾아서 수정해주어야 합니다.
또한 DTO로 묶었을 때 가질 수 있는 별도의 가공 기능이라던지, 검증 절차 등은 말씀하신 방법으로 데이터를 서빙할 때에는 활용할 수 없게 됩니다. (로직이 Controller나 Service 여기저기로 분산되겠죠?)

그리고 보통 실무에서는 조금만 복잡해져도 API 하나의 필드가 많으면 수십 개에 이르기 때문에, 애초에 가독성이나 유지보수 측면에서도 이점을 가져가기가 어렵습니다. ㅎㅎ

도움이 되셨기를 바랍니다.
감사합니다. 😊

안녕하세요, 인프런 AI 인턴입니다.
psam1017님, 질문 주신 내용대로 Controller에서 받은 Dto의 컬럼들을 풀어서 Service단으로 넘겨주는 방법에 대한 제 생각을 말씀드리겠습니다.

DTO는 계층간 데이터 교환을 위해 사용되는 객체로, 한 계층에서 다른 계층으로 데이터를 전달할 때 사용됩니다. Controller에서 Service로 데이터를 전달할 때 DTO를 그대로 전달하는 접근 방식은 간결하고 관리하기 쉬운 장점이 있습니다. 또한, Service 계층에서는 비즈니스 로직에 집중할 수 있어야 하며, DTO를 통한 데이터의 전달은 이러한 책임 분리를 잘 나타냅니다.

그러나 Controller에서 받은 DTO의 각 컬럼을 개별적으로 분해하여 Service 계층에 전달하는 방식이 비즈니스 로직에 보다 명확하고 직접적인 접근을 제공한다고 생각하실 수도 있습니다. 이 경우, 각 파라미터를 명시적으로 다룰 수 있어 메서드의 시그니처를 통해 인터페이스를 더 쉽게 이해할 수 있습니다.

하지만 이 방법의 단점도 있습니다. 만약 DTO가 포함하고 있는 데이터의 양이 많다면, 메서드 시그니처가 복잡해지고 매개변수 관리가 어려워질 수 있습니다. 또한, 파라미터 목록이 길어지기 때문에 메서드를 호출할 때 오류가 발생하기 쉬워지며, 유지 보수 측면에서도 한 DTO 내의 필드가 변경될 때마다 관련 메서드의 시그니처도 함께 변경해야 하는 번거로움이 있습니다.

따라서, 상황에 따라 DTO를 그대로 전달하는 것이 나을 수도 있고, 필요한 데이터만 선택적으로 전달하는 것이 나을 수도 있습니다. 유지 보수성, 코드의 명확성, 개발자 간의 커뮤니케이션 방식 등 다양한 요소를 고려하여 적절한 방법을 선택하는 것이 중요합니다.

psam1017님의 상황에서 가장 효과적인 방식이 무엇인지 고려해 보시기 바랍니다.