ProductController 에서 타협하지 않는다면 어떤 형태가 되나요?

Question

현재 Controller 클래스는 온전히 순수하지 않다(9강 11:51)고 말씀해주셨는데 온전히 순수한 Controller 클래스는 어떤 형태여야 하는지가 궁금합니다. 제가 봤을때는 지금 Controller 가 프레젠테이션 레벨의 productAssembler 를 호출해서 포맷팅만 바꿔서 내려주고 있기 때문에 로직적인 부분이 클래스에 없어서 순수해보이는데요. 혹시 productAssembler 에서 isUnique 를 계산해주고 있어서 순수하지 않다고 표현하신 걸까요?? 어디서 타협을 하셨다는건지 잘 이해가 되지 않아서 설명해주시면 감사하겠습니다!

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴입니다. 조예인님 질문하신 Controller의 순수성 , Assembler에서 계산을 수행해도 되는지 , Controller와 Service의 책임 분리 와 관련된 기존 답변을 참고해 보시면 좋습니다. 관련 질문 Controller에서 비즈니스 로직 흐름이 나타나는 것에 대하여.. Controller에서 여러 Service를 직접 조합할지, 하나의 상위 Service가 비즈니스 흐름을 담당할지에 대한 논의입니다. 단순한 데이터 전달과 변환을 넘어 주문·쿠폰·포인트 등 업무 흐름을 Controller가 직접 관리하게 되면 Controller의 책임이 커질 수 있으며, 기능이 복잡해질수록 하위 컴포넌트를 응집시키는 방향을 고려할 수 있다고 설명합니다. 주문 - 개념 격벽 의존 방향과 실제 코드의 의존 방향 불일치 질문 Controller는 외부 요청을 받아 내부 개념을 표현하는 표현 영역 으로 볼 수 있으며, 여러 응집된 비즈니스를 조합하는 Facade가 반드시 하나의 도메인 개념이 되는 것은 아니라는 내용이 담겨 있습니다. 따라서 Controller가 단순히 요청을 해석하고 적절한 처리 컴포넌트를 호출하는 정도라면, 어느 정도의 조합은 허용될 수 있습니다. 질문하신 productAssembler 가 단순히 도메인 객체를 응답 DTO로 변환하거나 표현 형식을 바꾸는 역할이라면 Controller와 함께 프레젠테이션 계층의 책임으로 볼 수 있습니다. 다만 isUnique 가 단순한 표시용 값이 아니라 여러 도메인 데이터를 조회·판단하거나 업무 규칙을 적용해 계산하는 값이라면, 해당 계산은 Service나 별도의 응집된 컴포넌트로 이동하는 편이 자연스러울 수 있습니다. 즉, “순수한 Controller”를 기계적으로 로직이 전혀 없는 클래스로 보기보다는, HTTP 요청·응답 처리와 프레젠테이션 형식 변환에 집중하고 도메인 규칙이나 복잡한 비즈니스 흐름은 갖지 않는 Controller 로 이해하시면 좋습니다. 어느 지점까지 허용할지는 isUnique 의 의미와 변경 이유를 기준으로 판단하는 것이 핵심입니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.