제품상세 코드 느끼기
안녕하세요 제미니님 유투브때부터 잘 보고 있습니다!
그 25분쯤에 controller에 여러 service들을 주입받아서 사용하시는 부분에 대한 질문이 있습니다.
1. 그럼 격벽으로 넘어도 되는 개념 사이에서는 a service에서 b finder or b appender 를 호출해도 괜찮은건지..?
2. 격벽으로 넘어서 안돼는 개념 사이에서는 강의에 나온것처럼 여러 service를 controller에서 받아서 response를 만들어야 하는건지.....?또 그렇게 되면 controller에서 여러 service를 알아야하니까 그건 또 문제가 없는지.. 궁금합니다!!
제미니님은 주로 어떻게 하시나요!?
감사합니다
답변 2
1
안녕하세요 질문 감사드립니다!
[질문1]
제가 개념도를 활용하는 전략에서는 말씀해주신 방식으로 호출해도 괜찮습니다!
격벽을 세워서 개념들의 참조를 통제하고 제어하기 위한 것이니까요!
[질문2]
이건 전략에 따라 다릅니다만 저는 보통 Controller (Presentation Layer)는 덜 중요하고, 개념을 나타내는 영역이 아니라고 생각합니다.
그러므로 Controller 에서 Service 를 조합하는 것도 한가지 방법 중 하나라고 생각합니다!
그래서 Controller 에서 Service 여러개를 조합하는 것 자체가 격벽을 넘는 행위라고 지칭하지 않습니다
결국 개념과 격벽을 그리는 이유는 비즈니스,구현 도구 영역을 적절히 지켜내고 계속 성장할 수 있도록 관심을 가지기 위한 수단이기 때문에 그쪽에 집중하는게 맞다고 생각합니다
그 외에는 별개로 Controller에서 Service 조합하는 로직은 이질적이실 수 있습니다 (사실 저도 실무에서 잘 안씁니다ㅎㅎ)
대신 그 상위에 대한 영역을 만들거나 컴포넌트를 만드는 선택을 할 수 있습니다 (Facade, WrapperService, Wrapper 등등) 그것 또한 고민거리니 한번 생각해보시면 좋을 것 같습니다!
관련해선 유사 질문이 있었어서 이 질문의 답변도 참고 부탁드립니다!
모쪼록 답이 되었길 바랍니다! 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다. wnsqud70님.
서비스 아키텍처를 설계할 때, 특히 컨트롤러에서 여러 서비스를 주입받아 사용해야 하는 상황이 자주 발생할 수 있습니다. 이와 관련된 질문을 해결하기 위해 아래 내용을 참고해 주세요.
1. 개념 간 격벽과 서비스 호출
격벽 넘기가 가능한 경우: 서로 다른 도메인 객체 간에 비즈니스적으로 연관된 경우, A 서비스에서 B 서비스(Finder나 Appender)를 호출하는 것이 가능합니다. 다만 이때도 도메인 간의 결합도를 최소화하기 위해 인터페이스를 통해 의존성을 설정하고, 각 서비스의 책임을 명확히 구분하는 것이 좋습니다.
레이어드 아키텍처에서 서비스 간 호출은 자연스러운 흐름일 수 있으며, 이는 비즈니스 로직이 여러 서비스에 걸쳐있을 때 특히 필요합니다.
2. 격벽을 넘지 않는 경우의 컨트롤러 역할
격벽을 넘지 않아야 할 경우: 격벽을 넘으면 안 되는 경우, 컨트롤러는 다수의 서비스를 주입받아 사용하며, 직접적으로 필요한 각 서비스를 조합하여 응답을 구성해야 합니다. 이때 여러 서비스를 주입받는 것이 문제가 되지는 않습니다. 다만, 이로 인해 컨트롤러의 코드가 복잡해질 수 있으므로 Facade 패턴을 활용하여 여러 서비스의 호출을 캡슐화하는 것도 좋은 방법입니다.
컨트롤러가 가지는 책임: 일반적으로 컨트롤러는 사용자의 요청을 받아 이를 적절한 서비스 로직으로 전달하는 역할을 합니다. 따라서 컨트롤러가 여러 서비스를 알아야 하는 것은 필연적일 수도 있지만, 중요한 것은 서비스 계층과의 분리를 명확히 줄 수 있도록 설계하는 것입니다.
이에 대한 추가 정보와 실제 사례 논의를 원하신다면, 다음 링크들을 참고하시면 도움이 되실 것입니다:
이 답변이 wnsqud70님의 질문에 대한 충분한 논의를 제공하기를 바랍니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
다양한 관점의 코드 경험을 위해 개선하지 않은 코드
1
47
1
histories() 응답에 PointHistory.id를 포함한 이유가 궁금합니다/
1
44
2
SettlementTargetRepository Jquery 질문
1
48
2
부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?
1
60
2
엔티티의 pk 를 0으로 초기화하시는 이유가 있을까요??
1
67
2
제미니님 안녕하세요!
1
73
2
개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조
1
80
2
프로덕트와 프로덕트카테고리 사이의 삭제 정책
1
75
2
새로 개발한다면 구현 순서
1
133
1
의존 방향에 대한 고민
1
122
2
어드민(Back-office)에서 예약 변경 시, '할인 조건 재검증(쿠폰 회수)' vs '기존 혜택 유지' 중 어떤 정책이 일반적인가요?
1
95
2
OrderKeyGenerator 인스턴스화 generate() 질문
1
83
1
외부 API 통합 시 데이터 제어 범위 설계 질문
1
96
1
PG 결제 승인 로직
1
128
2
QnA에서 Join 필드 표현법
1
88
1
결제서비스 콜백 동시성문제 가능성
1
106
2
굿
1
107
1
도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법
1
135
2
도메인 객체와 엔티티 객체 사용
1
137
2
CouponService 의존성 의문
1
96
2
상품 목록 조회 고도화 질문
1
111
2
표현 계층에서의 접근 지점이 다양해지는것과 이를 해결하기 위한 파사드의 도입에 대해 제미니님의 생각이 궁금합니다.
1
123
2
격벽의 순환 참조(?)
1
113
2
결제 관련 서킷 브레이커 전략, 데이터 정합성 및 타임아웃 설정 질문
2
174
2