mvvm과 clean architecture

Question

클린아키텍쳐와 mvvm을 공부하고있는데

오리지널 클린아키텍쳐와 안드로이드에서의 클린아키텍쳐가 조금 다르더군요.

그런데 안드로이드에서의 클린아키텍쳐와 mvvm의 차이점이 궁금합니다.

이 둘은 엄연히 다른건가요?

 

이제 글들을 읽고 샘플 코드도 대강 어떻게 되어있는지 막 보고는 있는데

클린아키텍쳐기반과 단순 mvvm으로 이루어진 코드가 조금씩 다르더라구요.. 샘플코드라 규모가 작은탓인지..

 

예를들면

클린아키텍쳐에서의 샘플코드들은 usecase를 다 나누고

viewmodel 클래스에서 usecase들에 의존적(?)인 코드를 짜던데요..

class MovieSearchViewModel(
    private val getMoviesUseCase: GetMoviesUseCase,
    private val getPagingMoviesUseCase: GetPagingMoviesUseCase,
    private val getLocalMoviesUseCase: GetLocalMoviesUseCase,
    private val networkManager: NetworkManager
)

이런식으로요,

 

그런데 mvvm으로 만들었다는 코드들을 보면

public class AuthViewModel extends AndroidViewModel {

    private AuthenticationRepository repository;

    ....
}

 

이런식으로 repository를 사용하더라구요. (번외로 이건 의존성?이아니죠? 직접생성하는건 의존성이아니라고 하던데..)

 

암튼 이렇게 차이점이 있던데.. 이건 대충의 예시이구요. mvvm 패턴 샘플 코드를 

보면 클린 아키텍쳐에서는 usecase 도 나누고 , repository도 인터페이스와 respotoryImpl 을 나누어 사용하고

막 그러던데.. 

 

좀 헷갈리더라구요 클린아키텍쳐와 mvvm을 묶어서 생각하려니.. 어떻게 다를까요?

 

++)참고로 파이어베이스 사용하려고 합니다. 대부분의 클린아키텍쳐 샘플코드가
로컬 DB(Room, SQL lite) 혹은 Remote DB (Retrofit? Http?) 등이런것을 사용해서 좀달라서 그런데 파이어베이스를 사용하면 클린아키텍쳐가 좀 달라져야한다는것이 있을까요?

 

Answer 1

Clean Architecture는 Architecture - 건물 설계도와 같은 소프트웨어 설계도라고 보시면 되구요.
MVV - Model-View-ViewModel, 이건 디자인 패턴입니다.

패턴과 이키텍쳐는 다른 의미입니다. 패턴은 소프트웨어 구현시 반복적으로 발생되는(이게 패턴이죠) 문제점들을 해결하기 좋은 방법을 구조화시킨 것이라고 보면 될 것 같습니다.

두가지 모두 개념만 존재할 뿐 실제적인 구현은 구현자의 이해와 선호사항에 따라 많이 달라질 수 있고 정답은 없습니다. 그래서 인터넷을 찾아보면 구현방법들이 차이가 나는 경우가 많습니다.

Clean Architecture의 핵심은 양파 모양의 아키텍쳐로, 도메인 레이어가 제일 안쪽에 UI레이어가 가장 바깥쪽에, 데이터 레이어가 그 사이에 위치합니다. 각 레이어 간에 최대한 의존관계를 줄이고 도메인 레이어의 경우 가장 독립적인 계층으로 다른 곳으로 옮겨도 그대로 사용할 수 있도록 portable하게 만들게 됩니다. 따라서 구현된 코드들을 보면 도메인 레이어에는 인터페이스만 존재하고 데이터 레이어에 이 인터페이스에 대한 구현체가 존재합니다. 그리고 대부분의 Clean Architecutre의 구현에는 Mapper라는 것이 존재하는데, 이건 다른 레이어에서 사용되는 데이터 모델을 변환시켜주는 컨버터입니다. 즉, API의 읃답 모델을 도메인레이어에서 사용하는 클래스로, 도메인 레이어에서 사용하는 데이터모델을 UI레이어에서 사용하는 데이터 클래스로 변환을 시키는 역할을 합니다. 또는 반대방향에도 사용됩니다. Clean Architecture 는 자연스럽게 Mapper가 엄청나게 많이 사용되는 경향이 있습니다.

Clean Architecture의 구현에서 ViewModel이 많이 사용되는 이유는 ViewModel에 LifecyeAware 컴포넌트라 그렇습니다.  Configuration change에서 살아남을 뿐 아니라, SavedStateHandle를 사용하면 Process death에도 대처할 수 있는 기능을 제공하기 때문입니다. Clearn Architecture가 꼭 MVVM을 사용할 필요는 없습니다.

Clearn Architectuere를 사용하게 되면 상당히 많은 클래스를 만들어야 합니다. 하지만 이걸 단점이라고 할 수는 없습니다. 대부분의 업무용 앱은 도메인 레이어가 존재하더라도 이렇다할 비지니스 로직이 차지하는 비중이 많이 낮습니다. 이것 때문에 도메인 레이어를 두는 것은 불필요하다는 논쟁이 있습니다. 그리고 개발자에 따라서는 Repository와 UseCase를 모두 사용해야 한다고 주장하기도 하고, UseCase나 Repository면 된다는 주장도 있습니다.

아키텍쳐에는 정답이 없습니다. Clean Architecture 또한 Uncle Bob이 만들어 낸 사적이 의견이 많이 들어간 아키텍처의 하나입니다. 여기에 따르고 말고는 프로젝트의 규모,  팀원의 수준, Clean Architecture를 사용해서 얻는 이득과 손실 등을 고려해서 결정할 사항이라고 봅니다. 그리고 어떤 아키텍쳐나 프레임워크도 완벽하지 않기 때문에 그 선택에는 항상  trade-off(득과 식)이 따라는 법입니다. 따라서 득이 많고 실이 적은 아키텍쳐를 선택하면 되는 거라고 생각합니다.