📱 Android
[Android] 클린 아키텍처 적용 시 고민했던 3가지 의문점
콩드로이드
2025. 4. 12. 11:56
새 프로젝트를 시작하며 새로운 디자인 패턴(MVI)를 적용하려고 하다보니, 클린 아키텍처에 대한 고심?이 필요했습니다
들었던 의문점들을 정리해보았어요 🥹
🔒 Q1. Repository는 화면을 따라가야 할까? 데이터 주체를 따라가야 할까?
🔑 A. Repository는 무조건 “데이터 주체” 기준으로 네이밍해야 함!
- ❌ MainRepository, BookScreenRepository
- ✅ BookRepository, UserRepository
: Repository는 데이터 주체를 중심으로 만들어야 여러 화면에서 재사용 가능하고, 구조가 깔끔하게 유지
🔒 Q2. Repository는 domain 계층인데, 구현체는 왜 data에 있을까?
🔑 A. Repository의 정의는 도메인에 있고, 실제 구현은 data에 있어야 함!
- BookRepository (interface) → domain
- BookRepositoryImpl (구현체) → data
: 이유는 도메인은 외부 기술(Retrofit, Room 등)을 몰라야 하기 때문
→ 기술 독립성 유지가 클린 아키텍쳐에서 제일 중요함!
🔒 Q3. UseCase에서 Repository 호출하면, 결국 어차피 Repository의 구현체(RepositoryImpl)가 동작하는 거 아닐까?
그럼 UseCase를 사용할 필요가 있나?
🔑 1. 계층 간 의존 역전 원칙(DIP)을 지키기 위해
- 구현체가 동작하긴 하지만 UseCase나 Repository는 인터페이스 기준으로만 동작해야 함!
- UseCase는 BookRepository를 부르고, 실제로는 Hilt가 BookRepositoryImpl을 주입해주는 구조
: UseCase나 Repository에서 외부 기술을 직접 사용하면 계층 간 의존 역전 원칙(DIP)이 깨짐
상위 계층이 하위계층에 의존하면 X, 인터페이스에만 의존해야함!
🔑 2. 관심사 분리로 유지보수성과 테스트성을 높이기 위해
- ViewModel은 상태 관리와 UI 이벤트 처리만 담당
- UseCase는 비즈니스 로직, 데이터 처리 등의 실제 기능을 담당
이렇게 분리하면 각 계층이 하나의 책임만 갖게 돼서
→ 로직이 더 깔끔해지고
→ 테스트 작성, 기능 확장, 유지보수 용이
항상 프로젝트 구조를 짜는 게 제일 어려운 거 같아요 꾸준한 연습하기,, !