[Android] 클린 아키텍처 적용 시 고민했던 3가지 의문점

새 프로젝트를 시작하며 새로운 디자인 패턴(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는 비즈니스 로직, 데이터 처리 등의 실제 기능을 담당

이렇게 분리하면 각 계층이 하나의 책임만 갖게 돼서 
→ 로직이 더 깔끔해지고
→ 테스트 작성, 기능 확장, 유지보수 용이 

 

---

항상 프로젝트 구조를 짜는 게 제일 어려운 거 같아요 꾸준한 연습하기,, !