인프런 커뮤니티 질문&답변
작성자 없음
작성자 정보가 삭제된 글입니다.
상품 상세 컨트롤러 내 서비스 참조 질문
작성
·
12
0
강의에서 상품 상세 컨트롤러에서 여러 개의 서비스를 직접 참조해 하나의 응답으로 반환하고 있는데요
이 경우, 단일 서비스에서 데이터를 묶어 응답하지 않고 각 서비스를 개별적으로 호출하는 이유가 궁금합니다.
이런 구조가 모듈을 분리했을 때 Aggregation 성격의 서비스가 여러 서비스에 의존하게 되는 문제를 피하기 위한 설계인가요?
또, 여러 서비스를 호출하면 하나의 API 요청 내에서 여러 트랜잭션 커넥션이 열릴 수 있는데, 이를 설계 상 트레이드오프로 봐야 할까요?
추가로, 강의에서는 productId 하나만 받아서 여러 서비스를 독립적으로 호출하고 있는 것 같았는데,
서비스 간 호출 순서가 없으므로 각각을 독립적인 유즈케이스로 보는 게 맞을까요?
아니면 컨트롤러가 여러 서비스를 조합하는 역할을 가져도 되는 걸까요?
마지막으로, 저는 조회 시 실무에서는 모듈별 유즈케이스가 각각 존재하고, 이를 묶어주는 별도의 서비스가 로직과 조합을 포함하여 담당하고 있습니다.
예를 들어 상품 조회 API 응답 시 상품내용과 함께 회원 이름/생년월일 등등 포함, 쿠폰 정보 포함 요구사항이 주어졌을 때
두 가지 방식으로 구현할 수 있을 것 같은데요
어떻게 바라보시는지 궁금합니다.
# 방법1
# 특정 서비스에서 조합하여 호출
상품 API 모듈(컨트롤러) → 상품 Service 모듈 → 회원 모듈 서비스1, 쿠폰 모듈 서비스2, ...# 방법2
# 각 서비스를 컨트롤러에서 호출
상품 API 모듈(컨트롤러) → 회원 모듈 서비스1, 쿠폰 모듈 서비스2강의에서는 방법2 와 비슷하게 처리하신 것 같습니다.
강의 중 여러가지 패턴을 소개해 주신다고 했지만 급하게 질문드리는 점 죄송합니다.
답변 1
0
안녕하세요, 인프런 AI 인턴입니다.
noose님께서 질문하신 내용을 바탕으로 여러 서비스 호출 구조에 대해 답변 드리겠습니다.
여러 서비스를 개별적으로 호출하는 이유:
강의에서 여러 서비스를 독립적으로 호출하는 것은 각 서비스의 독립성을 유지하고, 모듈 간 결합도를 낮추기 위함일 수 있습니다. 이는 모듈을 분리했을 때, Aggregation 성격의 서비스가 여러 서비스에 의존하게 되는 문제를 피하려는 설계 전략일 수 있습니다.여러 트랜잭션 커넥션 발생 및 설계 트레이드오프:
하나의 API 요청 내에서 여러 트랜잭션 커넥션이 열리는 것은 설계상의 트레이드오프라고 볼 수 있습니다. 각 서비스가 독립적으로 동작하여 각각의 트랜잭션 컨텍스트에서 작업할 수 있으므로 데이터 일관성과 서비스 독립성을 유지할 수 있습니다.서비스 호출 순서 및 컨트롤러 역할:
여러 서비스 호출 사이에 순서가 없다면, 각 호출을 독립적인 유즈케이스로 볼 수 있습니다. 컨트롤러가 여러 서비스를 조합하는 역할을 수행하는 것도 가능합니다. 다만, 설계에 따라 모든 로직이 컨트롤러에 집중되지 않도록 주의해야 합니다.실무에서의 모듈별 유즈케이스와 서비스 조합:
실무에서는 noose님이 언급하신 것처럼 모듈별로 유즈케이스가 존재하고, 이를 조합하는 별도의 서비스가 로직을 담당하는 것이 일반적입니다. 두 가지 방법 중 선택은 시스템의 의도와 요구사항에 따라 달라질 수 있습니다.
두 방식의 장단점을 고려하여 선택하시되, 요구사항과 시스템 구조에 가장 적합한 방법을 채택하시면 좋겠습니다. 특히, 방식1의 경우는 조합 로직이 명확하고 중앙화된 관리가 필요할 때, 방식2는 각 서비스의 독립성이 중요할 때 적합할 수 있습니다.
강의를 기반으로 다양한 패턴을 학습하시면서, 주어진 상황에 가장 적합한 설계를 찾아가실 수 있기를 바랍니다.
Spring Data JPA - Reference Documentation
Spring Boot Reference Documentation