인프런 커뮤니티 질문&답변
작성한 질문수
inteface UserRepsotiroy 를 service 패키지로 뺀 이유에대해서 궁금합니다.
해결된 질문
작성
·
647
·
수정됨
2
service 레이어는 repository 보다 상위 레이어에 있습니다.
일반적으로 service 레이어는 repository 를 주입받아서 사용됩니다.
OOP 원칙에서도 상위레이어는 하위레이어를 알아도 괜찮은것으로 알고있습니다. 반대로 하위레이어는 상위레이어를 알아서는 안됩니다.
'외부 연동을 다루는 방법' 강의 1:53 ~ 2:04 에
상위 레이어인 Service 가 infraStructure 에 의존하는 모습을 보이기때문에 라고 하셨습니다.
이말을 해석하면, 앞으로 변경될 코드에서는 UserService 는 interface 인 UserRepository 를 의존하게됩니다. 그러나 자세히 들어가면 service 레이어가 UserRepository 에 의존하는것이 아닌 의존성역전을 통해 그의 Impl 을 받게됨으로 약결합이 되게됩니다. 그러므로, service 가 interface 인 UserRepository 에 의존하는건 아니기때문에 service 패키지로 해당 interface 를 옮긴것인지 궁금합니다.
답변 3
1
안녕하세요. 근래에 책을 집필할 기회가 생겨 그쪽에 힘을 실어주다 보니 다른 일에 신경 쓰지 못했습니다. 답변이 늦어 죄송합니다. 다만 해당 강의는 공식적으로 질의응답을 제공하지 않는 강의였다는 점을 이유로 늦어진 부분에 대해 양해 부탁드립니다.
우선 저의 안 좋은 습관이 옮은 것 같아 먼저 정정해 드립니다. service 레이어가 아니라 applicaiton 레이어라 부르는 것이 맞습니다. 제가 applicaiton 레이어를 service 레이어라 부르는 습관이 있는데, 이게 강의에 그대로 찍혀있더라고요. 최대한 빨리 수정하겠습니다;;
질문 주신 내용에 관해서는 후속으로 달아주신 댓글처럼 이해해 주신 내용이 맞습니다. UserRepository가 infrastructure에 있다면 applicaiton 레이어가 infrastructure 레이어에 의존하는 그림이 됩니다. 이를 피하기 위해 UserRepository를 applicaiton 레이어에 위치시킨 것입니다.
덧으로 레이어의 상하 관계는 고정적이지 않습니다. 전통적인 레이어드 아키텍처를 추구하는 누군가는 infrastructure 레이어를 최하위 레이어로 봅니다. (참조: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html 여기서는 infrastructure 레이어를 persistence layer라고 보네요) 한편 헥사고날 아키텍처를 추구하는 또 다른 누군가는 infrastructure 레이어를 최상위 레이어로 봅니다. (참조: https://medium.com/@luishrsoares/whats-hexagonal-architecture-6da22d4ab600 여기서 infrastructure 레이어가 가장 바깥에 존재한다는 것을 유심히 봐주세요.)
그러니 일단 레이어드 아키텍처의 틀에서 벗어나길 추천드립니다. 전통적인 레이어드 아키텍처는 좀 이상한 부분이 많습니다.
+) 소프트웨어 설계를 설명하는데 통용될 수 있는 단 하나의 원칙 같은 게 있는 것은 아닙니다. 예를 들어 “상위 레이어는 하위 레이어를 참조해선 안 된다.”라는 원칙 하나만으로 소프트웨어를 이해하려 한다 가정해 봅시다. 그런데 이 원칙을 본 강의에서 설명하는 아키텍처에 적용하려 보면 많은 모순이 있습니다.
상위 레이어에 위치한 application 레이어가 하위 레이어에 위치한 domain 레이어를 참조하고 있습니다. 또 한편 하위 레이어에 위치한 infrastructure 레이어가 상위 레이어인 application 레이어를 참조하게 만들고 있고요. (물론 이는 레이어드 아키텍처를 헥사고날 스타일에 맞게 재정렬하면서 해소가 됩니다.)
답변이 도움 됐길 바랍니다.
0
다시 복습하니 이해됐습니다. 앞선 강의에서 UserRepository interface 는 service Layer 로 분류를 해주었고,만약 UserRepository 가 infrastructure 에 있다면 해당 layer 에 의존하는 형태처럼 보였기때문이였네요.
0
안녕하세요, 인프런 AI 인턴이에요. interface UserRepsotiroy 를 service 패키지로 옮긴 이유에 대해 궁금하신 것 같아서 답변 드릴게요.
service 레이어는 일반적으로 비즈니스 로직을 담당하고, repository 레이어는 데이터베이스와의 상호작용을 담당합니다. 이렇게 레이어를 나누는 이유는 코드의 유지보수와 확장성을 높이기 위해서입니다.
interface를 사용하는 이유는 의존성 역전 원칙(Dependency Inversion Principle, DIP)을 준수하기 위해서입니다. DIP는 상위 레이어가 하위 레이어에 의존하지 않고, 하위 레이어가 상위 레이어에 의존하도록 설계하는 원칙입니다. 이렇게 하면 상위 레이어와 하위 레이어 사이의 의존성이 줄어들어 약결합(Loose Coupling)이 가능해집니다.
따라서, service 레이어가 interface인 UserRepository에 의존하는 것이 아니라 UserRepository의 구현체를 주입받아 사용합니다. 이렇게 하면 UserRepository의 구현체를 변경해도 service 레이어는 영향을 받지 않고 동작할 수 있습니다. 따라서, service 레이어에서 UserRepository를 import해서 사용하는 것이 아니라, UserRepository 인터페이스를 service 패키지로 옮긴 것입니다.
이렇게 하면 service 레이어는 UserRepository 인터페이스에만 의존하고, 실제 구현체는 외부에서 주입받아 사용하게 됩니다. 이는 코드의 유연성과 확장성을 높여줍니다.
한편, OOP 원칙에서는 상위 레이어가 하위 레이어를 알아도 괜찮다고 설명되었을 수 있습니다. 그러나 위에서 언급한 의존성 역전 원칙을 따르기 위해 service 레이어에서는 UserRepository 인터페이스만을 의존하도록 설계하는 것이 일반적입니다.
저희가 설명한 내용이 도움이 되셨기를 바라며, 더 궁금한 점이 있다면 언제든지 물어보세요. 좋은 하루 되세요~!