계층 관련 질문이 있습니다.

Question

위 강의에서는 Response 부분을 service 레이어에 response 패키지 안에 관리를 하고 있습니다. 개인적인 생각으로는 요청을 받는 부분은 최상단 Presentation Layer 이고 궁극적으로 어떠한 결과를 return 해주는 것 또한 Presentation Layer 이라고 생각합니다.   그렇기에 requestDto 는 controller 쪽에 있는게 맞고 responseDto 또한 controller 쪽에 있어야 하는게 맞지 않을까 하는 생각이 듭니다! 혹시 위 부분 어떻게 생각하시는지 궁금합니다.

시안 · Answer

소스코드 어디서 볼 수 있나요 ?

박우빈 · Answer

안녕하세요, 압구정 자발개 님! 네, 맞습니다. 강의 예제는 간단한 프로젝트이기 때문에 Service에서 반환하는 Response를 그대로 사용했는데, 이대로도 사실 의존 관계 상 큰 문제는 없습니다. 만약 실제 최종 응답에 사용되는 형태와 Service에서 반환하는 데이터의 형태가 달라야 한다면, 각 레이어에 DTO를 별개로 두고 변환 과정을 거쳐야 할 거예요. (강의 중에 Request가 계층을 넘어오면서 변환 과정을 갖도록 했던 것 처럼요.) 도움이 되셨기를 바랍니다. 감사합니다. 🙂

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. 압구정 자발개님, 질문 주셔서 감사합니다. DTO(Data Transfer Object)의 위치에 대한 논의는 소프트웨어 아키텍처에서 빈번한 주제 중 하나입니다. DTO를 어떻게 배치하느냐에 따라 계층 간 의존성과 응집도가 서로 영향을 미칠 수 있기 때문인데요. 간단한 설명과 함께 기존에 관련된 토론에서 유사한 질문 사례를 추천 드리겠습니다. Presentation Layer와 의존성 : Presentation Layer는 사용자 인터페이스와 직접 연결되어 있으며, 이곳에서 Request와 Response를 처리합니다. 그럼에도 불구하고 Response DTO를 Service Layer에 두는 경우 는 종종 있습니다. 이는 비즈니스 로직 에서 직접 생성한 데이터를 저장하거나 조작할 DTO를 관리하기 위해서인데요, 비즈니스 로직의 결과물을 한 곳에서 통합 관리함으로써 응답의 일관성을 유지하고, 코드의 재사용성도 높일 수 있습니다. Controller의 책임 고려 : 요청과 응답을 다루는 것이 Controller의 주된 역할이라고 할 수 있지만, 이런 구조만 생각할 경우 Controller가 비대해질 위험이 있습니다. 이 경우 단일 책임 원칙(Single Responsibility Principle) 을 위반할 수 있게 되죠. 따라서 각 레이어의 역할을 명확히 하고, Service Layer에서 응답 객체를 만들어 Controller가 이를 사용하는 구조 는 유지보수성이나 코드 재사용성에서 유리한 점이 많습니다. 기존에 유사한 논의가 포함된 controller, service용 dto를 분리시키는 것에 대한 질문 에서 두 계층 간의 의존성을 어떻게 설정하고 관리할지에 대해 좋은 인사이트를 얻으실 수 있습니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.