나는 제대로된 Clean Architecture를 사용하고 있을까?

안드로이드 개발자들은 이제 Clean Architucture MVVM 패턴을 대부분 알고 있고 공통적인 개발 방향에 대해서 논의할 수 있을 정도의 기술 전파가 되었다고 본다. 

그래서 다른 사람들의 코드를 보더라도 예전처럼 구조 파악이 안되는 경우가 많이 없어졌다.
하지만 과연 MVVM 아키텍처를 완벽하게 구현하고 있는 회사는 얼마나 될까?
모두 제각각 자기 회사의 레거시 코드, 개발자 인원, api 규격 등에 의해서 맞춤형 MVVM 패턴을 적용하고 있을거라고 생각된다. 

사이드 프로젝트에는 내가 이해한 MVVM 패턴을 문제 없이 구현할 수 있다.
하지만 회사 코드는 내가 하고 싶은데로 할 수가 없어..

내가 오늘 정리하고자 하는 것은 이렇다. 

Clean Architecture는 크게 2가지로 구분되고 있다. 기본적인 2개의 아키텍처를 먼저 살펴보고, 내가 적용하고 있는 Clean Architecture는 어떤 모습인지 한번 살펴보려 한다. 
살펴볼 코드 기준은 Fernando Cejas 의 코드 예제를 기준으로 살펴보았다. 

1. Clean Architecture by Uncle Bob 

Uncle Bob이 누군데? 

그렇다. 이런 분이다. 

2. Clean Architecture by Google

1번과 다른점은 Repository가 Daya Layer로 이동했다는 점이다. 
그리고 Domain Layer는 생략이 가능하다. 

 

3. Boogil Clean Architecture

(Boogil은 접니다🤣)

실무에서 TDD 기반을 지향하긴 하지만, 실제로 그리 자주 사용되지는 않는다. 
api 통신에서 데이터를 만들기까지의 테스트 케이스를 만들어야 하는데 비지니스 로직이 그리 복잡한 경우가 아니라면 UI에서 확인하고 넘어간다. QA 팀이 있는 회사라면 더더욱 빠른 방향으로Test를 진행하기도 하니까. 

생략한 부분

• UseCase 생략
• Entity, Mapper 생략 

왜 생략했나?

Repository와 RepositoryImple을 나누는 것도 사실 일이다. Repository interface를 재사용하지 않는 경우가 많았고, ViewModel 에서 실제적으로 의존성 주입으로 Inject 되는 Impl 클래스를 찾으려면 DI 선언되어 있는 파일을 찾아가야한다. (툴에서 바로가기 제공이 안됨) 

@Provides
@Singleton
fun provideMoviesRepository(service: MovieService): MoviesRepository 
			= MoviesRepositoryImpl(service)

 

개인적으로 이런 고민이 많았습니다.

Repository와 RepositoryImpl로 interface와 구현체를 나누는 이점이 뭘까? 

ViewModel에서 구현체인 RepositoryImpl을 바로 참조하게 되면, RepositoryImpl을 수정하게 되면 바로 영향을 미치게 됩니다. 
RepositoryImpl의 파일명을 바꾸거나, 그 안의 함수의 리턴타입을 바꾼다거나 하게 되면 즉각적으로 ViewModel에 영향을 끼치게 됩니다. 

반면, ViewModel 에서는 Repository interface만 알고 있다면 완전한 분리가 가능해집니다. 구현체의 내용을 전혀 알 수 없고, 포멧팅이 Interface 에서 프로토콜 화 되어있기 때문에 ViewModel은 RepositoryImpl과 완전한 독립이 가능해집니다. 

Dependency Inversion (의존성 역전) 개념이 있습니다. 

1. 상위 수준의 모듈은 하위 수준의 모듈이 구체적으로 어떤 객체를 사용하는지 알지 못해야 한다. 
2. 추상화에 의존하여 구체적인 구현을 분리해야 한다. 

 

제가 내린 결론은 회사의 개발자 수에 맞춰서 Clean Architecture를 개조해야 한다는 것입니다. 

제가 속한 그룹은 3~4명의 안드로이드 개발자로 구성되어 있습니다. 

Suqad 조직을 운영하는 회사에서는 1 스쿼드에 1명의 안드로이드 개발자가 포진되어 있습니다. 

 

이런 경우에 Feature 개발을 하게될 때 각 개발자는 각 레이어를 모두 생성하여 진행을 하게 됩니다. 
이럴 때는 Repository 하나를 통해서 빠르게 작업하는게 낫다는 결론입니다.

작업자가 많은 회사의 경우, Layer를 나누어서 협업을 진행하게 될 수 있겠죠. 
이런 경우엔 interface, Impl 을 나누어서 작업하면 충돌을 방지하면서 클린한 방식으로 협업을 진행할 수 있을겁니다. 

 

---

다른 개발자 분들은 어떤 형식으로 MVVM 패턴을 실무에 적용하고 계실까요? 

무척이나 궁금합니다😃

---

<참고자료>
https://velog.io/@donghune/Clean-%EA%B3%BC-Google-Recommended-Architecture-%EC%9D%B4%EC%95%BC%EA%B8%B0

Clean 과 Google Recommended Architecture 이야기