NaverBookRepository.class 의 위치에 따른 모듈간의 의존성에 대해 질문드립니다.
27
6 câu hỏi đã được viết
학습관련 질문을 남겨주세요! 상세히 작성주시면 더 좋아요 🙂
안녕하세요, 강사님 🙂
이번 질문도 혼자 먼저 구현 후, 강사님의 강의를 들으며 리팩토링을 진행하며 궁금증이 하나 생겨 질문 드립니다.
저는 search-api 모듈의 com.library.repository의 NaverBookRepository.class 위치를 강사님과 다르게 external:naver-client 에 위치시켰습니다.(NaverBook/KakaoBook은 external 에 종속된 구현체라고 생각)
그러다 보니, naver-client 모듈이 search-api 모듈에 있는 BookRepository, PageResponse, SearchResponse 를 알아야 했으며, naver-client 모듈이 search-api 모듈을 implementation('...') 으로 의존?참조? 하게 되었습니다.
// search-api 모듈
public interface BookRepository {
PageResponse<SearchResponse> search(...);
}
이렇게 external -> search-api 로 흘러가는 의존 방향에 이질감이 듭니다.(외부 API 가 app 을 안다..?)
그래서 모듈간 의존 방향이 search-api -> external 되도록 강사님 강의처럼 NaverBookRepository 를 search-api 모듈에 위치 시켜도 NaverClient 때문에 search-api에 feign 종속성이 생긴 다는 것이 모듈간 의존성 격리가 되지 않아서 멀티모듈의 장점이 퇴색되었다고 생각합니다.
강사님은 과제가 아닌 실무에서 search-api 와 external 간의 모듈 격리를 어떻게 하시며, 의존 방향을 어떻게 하시는지 궁금합니다.
저의 부족한 지식을 확장할 수 있게 강사님의 인사이트 공유해주시면 감사하겠습니다!
Câu trả lời 2
1
아이고 종혁님! 요 질문이 메일로 알람이 안와서 놓쳤네요 😭 늦어서 죄송합니다!
굉장히 좋은 포인트를 또 찾아주셨네요. 이질감을 느끼신게 정확한 감각입니다.
완벽한 격리는 없고, 어디서 타협할지를 결정하는것이 실무에서 항상 하는 고민포인트인것 같습니다.
다만 개인적으로는 항상 같은 원칙을 적용하지는 않고있습니다. 크기가 점점 커져서 조금 더 나눠야될 필요성이 있다면 인터페이스와 도메인 모델을 별도 모듈(:search-domain)으로 추출해서, search-api와 external 양쪽이 모두 그 모듈만 바라보게 하는 방법도 있습니다. 이런 결정은 프로젝트의 크기에 따라 달리 선택하고있는데요, 프로젝트 사이즈가 상대적으로 작다면 너무 잘게 쪼개게되면 그것또한 오버엔지니어링이 될 수 있기때문입니다.
질문주신 "실무에서 search-api 와 external 간의 모듈 격리를 어떻게 하시며, 의존 방향을 어떻게 하시는지 궁금합니다." 이 내용에 대해서는 중간?정도 사이즈되는 프로젝트라면 강의에서 말씀드렸던 구조 그대로 사용합니다 ㅎㅎ
약간 주제에 벗어날수있는 얘기지만, 커리어 초반에는 꼭 무조건 이 원칙을 지켜야돼! 하면서 코드를 작성했었는데 시간이 지나면서 이런 사고들이 조금씩 바뀌었습니다. 나혼자 개발하는것이 아닌 팀원 전체가 동의하고 실수하지않고 최적의 효율을 내려면 구조를 어떻게 가져야할까? 정석적인 원칙보다는 우리 팀에 맞는, 우리 조직에 맞는 게 어떤걸까? 이런 효율측면에 조금씩 무게를 두게되네요.
제가 강의에서 말씀드린 이러한 구조도 특정 상황에서는 맞지 않을 수 있습니다. 정답은 없습니다. 종혁님께서 지금 이런저런 시도를 직접 해보시고 장/단점을 느껴보시는 연습이 추후에 종혁님께서 의사결정의 위치에 올라가시게될때 빛을 발하실거라고 확신합니다.
답변이 늦어 다시한번 죄송하고 해결되지 않은 궁금증이 있다면 언제나 편하게 남겨주세요!
0
안녕하세요, 인프런 AI 인턴입니다. 종혁님,
모듈 간의 의존성과 관련된 좋은 질문 감사합니다. 모듈간 의존성 관리와 그 방향성은 코드의 유지보수성과 확장성 측면에서 매우 중요한 주제입니다.
모듈간의 의존성 설계 방법
의존성 방향:
- 일반적으로는 비즈니스 로직을 담고 있는 모듈(ex:
search-api)이 외부 API 모듈(ex:external)을 참조하는 것이 자연스러운 의존 방향입니다. 이 방식으로 앱 자체의 비즈니스 로직이 외부 API에 비해 상위 계층에 위치하게 됩니다.
- 일반적으로는 비즈니스 로직을 담고 있는 모듈(ex:
인터페이스를 통한 해결:
- 외부 API에 대한 의존성을 강제로 분리하기 위해 인터페이스를 사용하여 내부 모듈에 드러나지 않도록 할 수 있습니다.
- 예를 들어,
external모듈에서 인터페이스를 정의하고search-api가 이 인터페이스를 구현하거나 참조하도록 하여 종속성을 역전시키는 방식입니다.
- 외부 API에 대한 의존성을 강제로 분리하기 위해 인터페이스를 사용하여 내부 모듈에 드러나지 않도록 할 수 있습니다.
모듈간 격리:
- 각 모듈은 자신만의 역할과 책임을 지며 다른 모듈에 최소한의 의존성만 갖도록 구조화하여 설계합니다.
search-api모듈은 비즈니스 로직 중심의 역할을 하고,external모듈은 외부와의 연동을 처리하여 서로 명확한 경계를 유지하도록 설계합니다.
- 각 모듈은 자신만의 역할과 책임을 지며 다른 모듈에 최소한의 의존성만 갖도록 구조화하여 설계합니다.
참고 링크
기존 답변에서는 모듈 간의 관계에 대한 몇 가지 유용한 관점이 제공됩니다. 다음 링크를 통해 확인해 보시면 도움이 될 것입니다.
- 멀티모듈 구성에서 하위 모듈은 java 모듈로 하는 이유가 궁금합니다. - 모듈 간 의존성과 설계의 일반적인 고려사항에 대해 다룸.
이런 해결책들이 종혁님의 구조적 고민을 해결하는 데 조금이나마 도움이 되길 바랍니다. 추가 질문이 있다면 언제든지 문의해 주세요. 곧 지식공유자께서 보다 심도 있는 답변을 제공해 주실 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
패키지 vs 모듈 선택 기준
0
48
2
Kotlin 테스트 프레임워크
0
79
2
import 오류?
0
70
2
JSON 역직렬화
0
63
2
Spring Cloud 버전 관리 문제
0
267
2
AsyncExcutor 설정값 질문
0
81
2
17강 api서버구현2 질문있습니다.(ai답변이 이상합니다.)
0
116
2
16강 api서버구현 질문있습니다.
0
76
2
14번쨰 부분 중 질문드립니다..<ai답변으로 해도 안되요>
0
143
2
.
0
142
1
서비스에 @Transactional 애노테이션을 사용하시지 않는 이유가 궁금합니다
0
156
2
NaverClientTest 질문있습니다.
0
179
2
멀티모듈 구성 질문입니다.
0
209
3
멀티모듈 구성 강의에 대해 질문이 있습니다.
0
214
3
SPOCK 의존성 추가 후 Generate Test 옵션 미노출
0
202
3
멀티모듈 지식 습득에 관하여 질문 드립니다.
0
250
2
Async Config 테스트컨트롤러의 코드의 동작이 안되는거 같습니다.
0
223
3
author 배열이 비어서 오는 경우가 있으니 참고하세요.
0
190
3
커밋 끊으면서 해주시는거 너무 좋네요.
1
158
2
비즈니스 로직 담당 서비스
0
197
2
모의과제 소개
0
176
2
cqrs에 관하여
1
253
2
멀티모듈 문의드립니다.
0
259
2
클린한 아키텍쳐에 관하여
1
231
2

