인프런 커뮤니티 질문&답변

안녕하세요, bamho 님!

이전 강의 중에 request DTO에 대해, Controller Request에서 Service Request로 변환해준 내용 기억나시나요?
Service 레이어가 Controller 레이어에 의존하지 않도록 DTO 간 변환 처리를 해준 것이었는데요.

마찬가지 이유로 현재 강의 예제의 Response 객체는 Service에서 만들어지기 때문에, Service 레이어 쪽 패키지에 두고 Controller가 이를 자연스럽게 의존하도록 둔 것이라 이해해주시면 됩니다.

레이어 간 의존성의 방향이 한 곳으로만 흐르도록 설계해 준 것이죠.

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

안녕하세요, 인프런 AI 인턴입니다. bamho님 질문 감사합니다.

ResponseDto의 위치는 프로젝트의 구조와 팀의 컨벤션에 따라 달라질 수 있습니다. 일반적으로 ResponseDto는 각 계층 간의 데이터 전송을 담당하고, 주로 서비스 레이어에서 생성되어 컨트롤러를 통해 클라이언트에게 전달됩니다. 그 이유는 다음과 같습니다:

1. 단일 책임 원칙: 서비스 레이어는 비즈니스 로직을 담고 있으며, 이 로직 처리 결과를 응답 객체로 생성합니다. 이때 ResponseDto는 비즈니스 로직의 출력 형태를 정의하기 때문에, 서비스 패키지 내에 두는 것이 일반적입니다.

2. 계층 간의 결합도 관리: ResponseDto는 서비스 레이어에서 주로 사용되지만, 컨트롤러 레이어 뿐만 아니라 다른 레이어에서도 사용될 수 있습니다. 따라서 특정 레이어에 의존성을 과도하게 만들지 않도록 서비스 패키지에 두는 것이 계층 간의 결합도를 낮추는 데 도움이 됩니다.

3. 재사용성: 프로젝트의 요구사항에 따라 다양한 서비스나 컨트롤러에서 동일한 응답 구조를 필요로 할 수 있습니다. 이 경우, 공통된 응답 객체를 서비스 패키지에서 관리하면 재사용성이 증가합니다.

관련해서 기존에 유사한 논의가 포함된 controller, service용 dto를 분리시키는 것에 대한 질문의 답변을 확인하시면 조금 더 구체적인 이해에 도움이 될 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.