인프런 커뮤니티 질문&답변
작성한 질문수
클린아키텍처 의존관계 관련
작성
·
73
·
수정됨
0
안녕하세요.
클린아키텍쳐에 대해 다시 공부하다가 근본적인 궁금증이 생겨서 질문 드립니다.
저는 강사님 강의를 수강하였고 구글에 여러 레포지토리를 참고하며 아래 구조로 프로젝트를 진행하였습니다.
그러나 최근 java + spring architecture 를 공부하다가 모바일쪽의 클린아키텍쳐와 일부 개념이 충돌하여 혼란을 겪고 있습니다.
위의 그림과 같이 바깥의 presentation/repository 와 같은 계층이 usecase 를 의존하여 개발해야 비즈니스로직(usecase / entity) 가 presentation/repository 의 변화의 의존적이지 않고 온전한 비즈니스 로직을 구현할 수 있습니다. 이러한 문제를 해결하기 위해 백엔드 진영에서는 헥사고날 아키텍쳐로 구현하는 듯 합니다.
참고) https://www.youtube.com/watch?v=saxHxoUeeSw
04:00 ~ 06:30, 08:20 ~ 14:00
모바일 진영에서는 domain layer 의 usecase 가 repository 를 그대로 참조하고 있어(물론 개념적으로는 인터페이스를 참조) repository 의 변경에 따른 usecase 변화로 비즈니스로직 및 도메인이 손상될 수 있다고 생각하는데 대부분 그냥 사용하고 있습니다.
그래서 제가 잘 못 이해한 것인지 아니면 다른 이유가 있는 것인지 강사님의 의견이 궁금합니다.
또한 Flutter 테스트 기초 다음 강의는 언제 나오는지도 궁금합니다 ㅎㅎ
감사합니다.
답변 2
0
인프런 AI 가 원래 하루 지나서 답을 하는데 이번에는 5분만에 달아버렸네요..ㄷㄷ
UseCase가 인터페이스를 참조하기 때문에 Repository 구현체가 로컬 DB이거나, 로컬 File 이거나, 리모트에 저장되거나 상관없이 UseCase 의 로직은 영향을 받지 않는 것이 맞습니다.
공유해 주신 영상 잘 보았습니다.
영상에서 이야기하는 부분과 제가 강의하는 부분이 추구하는 바는 일맥상통합니다.
객체가 다른 객체를 참조할 때는 인터페이스를 참조하는 것이 핵심인데요. 혹시 어느 부분에서 개념이 충돌하신다고 느끼셨을지 다시 알려주실 수 있으실까요.
이번 강의의 경우 클린 아키텍처 구조를 가져가지만 UseCase 없이 Repository 만 활용하고 있어서 그렇게 느끼셨을까요.
아키텍처에 대한 저의 생각을 말씀드리면
백엔드의 경우 많은 기능이 있고 이를 추상화하기 위해 헥사고날 같은 아키텍처를 고민하고 있고요.
모바일에서도 규모가 큰 앱의 경우 feature 별로 여러개로 나뉘어진 클린 아키텍처를 채용하기도 하기도 하고, MVI 기반의 클린 아키텍처를 채용하기도 하는 등. 다양한 변형이 가능합니다.
프로젝트의 규모에 따라 아키텍처는 정답이 없는 부분이기 때문이지요.
다음 강의는 고급편으로 열심히 만들고 있습니다. 이 강의에서도 앱 수준에 맞게 변형된 클린아키텍처를 사용하고 있습니다.
가제목은 "현업 수준의 Flutter 앱 작성" 이고요.
앱 사이즈가 커서 좀 오래 걸리고 있는데 10월 말까지를 목표로 하고 있습니다.
컨셉은 현업 스타일로 Figma 디자인이 주어지면 Mock 데이터를 토대로 앱을 작성하며, Unit Test, UI Test 가 가능한 형태로 코드를 작성하고 최종적으로 Integration Test 로 시나리오를 테스트할 수 있고, 코드 커버지리 목표를 설정하고 달성합니다.
개발 환경 설정을 통해 Mock 데이터와 실제 데이터를 쉽게 교체하고, 실제 데이터 구현체를 바꿔도 비즈니스 로직에 영향이 없는 코드를 작성합니다.
상태관리 코드의 의존성을 제거하여 쉽게 상태관리 라이브러리를 교체할 수 있고, UI 테스트가 가능하도록 코드를 작성합니다.
언급하신 부분 다시 보았습니다.
화살표가 UseCase <-- Repository 로 되어 있는 부분이네요.
위 그림, 계층형 아키텍처를 보면 제가 봤을 때는 그냥 클린 아키텍처인데요?
소스 코드가 어떻게 작성되는지 모르겠으나
제가 작성하는 방식에서는 UseCase 에 Repository 를 주입받기 때문에
제 수업 코드는 의존성 화살표를 UseCase --> Repository 로 표현하는게 맞고요.
두 번째 그림처럼 개발한다면
UseCase 인터페이스를 Repository 가 구현하다는 느낌일까요?
제 수업에서는 사용한다, 참조한다를 의존한다와 동일하게 설명합니다. 하지만 어떤 설명에서는 의존성에 대한 개념을 다른게 표현하기도 하는데요.
특히 DIP 의존성 역전 원칙의 경우, 많은 설명에서 의존성을 두번째 그림처럼 거꾸로 표현하며 설명하기도 합니다.
하지만 결국 바라보는 목표가 같고, 설명의 차이라고 생각합니다.
결국 구현체에 의존하지 않고, 추상화에 의존하자 라는 규칙을 지켜서 테스트 가능하게 작성하자에 수렴한다고 봅니다.
의존성 주입과 같은 개념은 알고 있었으나 의존성 역전 원칙에 대해 잘 알지 못했던 것 같습니다.
결국 고수준의 UseCase 가 저수준의 RepositoryImpl 을 직접 참조하는 것이 아니라 Domain 의 Repository Interface 를 참조하므로써 의존성 역전이 일어나 화살표가 반대방향이 되었다고 이해하게 되었습니다.
주말임에도 불구하고 정성스런 답변 감사드립니다.
다음 강의 "현업 수준의 Flutter 앱 작성" 도 기다리고 있겠습니다!
0
안녕하세요, 인프런 AI 인턴입니다.
김보겸님의 질문은 매우 전문적이며 클린 아키텍처의 구조와 의존성 관리에 관한 깊은 이해를 요구하는 내용입니다. 김보겸님께서 언급하신 클린 아키텍처와 관련된 프레젠테이션, 도메인, 영속성 계층의 관계 및 의존성에 대해 구체적으로 논의하고 있어, 아래에서 도움이 될만한 기존 답변을 참조하여 제공해 드립니다.
클린 아키텍처 질문에서는 클린 아키텍처의 레이어 간 구조와 Repository의 구현에 관한 일반적인 질문이 다루어졌습니다. 이 답변에서는 Domain 레이어와 Data 레이어의 Repository의 역할 및 분리 이유에 대해 설명합니다. 클린 아키텍처에서의 어노테이션을 통한 의존성 주입 등에 대해서도 다뤄 현재 질문에 대해 관련 설명을 제공할 수 있을 것입니다.
다른 관련 질문인 repository에 관하여에서는 MVVM 패턴을 사용할 때 repository를 도메인 레이어에서 추상클래스로 정의하고 데이터 레이어에서 구현하는 이유를 짧게 설명하고 있습니다. 이는 repository의 변경에 따른 use case 변화와 비즈니스 로직 및 도메인의 보호를 목적으로 하고 있어, 김보겸님의 질문에 부분적으로 접근하는 설명을 제공합니다.
현재 클린 아키텍처 및 헥사고날 아키텍처의 설계 원리와 응용에 대한 김보겸님의 이해를 돕기 위해 위 두 링크가 도움이 될 수 있습니다. 다만, 각각의 구체적인 의문점에 대해 더 깊이 탐구하고 싶으시다면, 해당 커뮤니티나 다른 전문가의 직접적인 답변을 추천드립니다.
레포지토리의 변경이 도메인 레이어에 미치는 영향과 이를 어떻게 완화할 수 있는지에 대한 논의는 클린 아키텍처를 실제 프로젝트에 적용할 때 중요한 고려 사항입니다. 클린 아키텍처의 핵심 목표 중 하나가 코드의 유연성을 높이고, 수정 및 테스팅을 용이하게 하는 것이기에, 추상화된 인터페이스(예: Repository)를 통한 각 레이어간 의존성 역전이 중요한 역할을 합니다.
Flutter 테스트 기초 다음 강의의 출시 일정에 대해서는, 정확한 정보를 제공해 드릴 수 없으나, 인프런 내 해당 강의의 공지사항이나 Q&A 섹션을 주기적으로 확인하여 강사님의 공지를 확인하는 것이 가장 좋은 방법일 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
주말인데도 답변 주셔서 감사드립니다.
저희 모바일의 클린 아키텍처가 영상 05:00 즈음 나오는 계층형 아키텍처와 같다고 생각했습니다. 그래서 클린 아키텍처가 맞나? 의문을 갖게 되었습니다. (영상에서는 이 계층형 아키텍쳐가 비 클린코드 라고 말합니다.)
영상에서 클린아키텍처 라고 이야기 하는 부분의 사진입니다.
도메인 영역 UseCase 로의 화살표 방향이 헷갈립니다.
Presenter(ViewModel) 이 UseCase 를 주입받는 것은 이해가 됩니다.
그런데 Repository 에서도 UseCase 를 주입받는 것으로 보이는데 이 부분이 헷갈립니다.
개념적으로는 이해가 되는데 코드로 구현할 때는 UseCase 가 Repository 를 주입 받지 Repository 가 UseCase 를 주입받고 있지 않기 때문입니다.
자꾸 귀찮게 해드려서 죄송합니다.