Android📱

안드로이드에서의 Clean Architecture와 Google Recommendation Architecture

아무루 2023. 10. 11. 20:08

어제 탈탈 털리고 헛소리만한 자신이 바보같아서 잠이 안 와서 공부하고 정리하는 글입니다. ㅠㅠ

누군가에게 조금이나마 도움이 되시면 좋겠습니다.

미래의 저에게도 도움이 되도록 정리해보았습니다.

저의 주관적인 생각이 많이 들어있어서 적당히 그렇구나~ 하고 보시면 좋을 듯합니다.

 

 

아키텍처란

컴퓨터 기술은 빠른 속도로 발전해 가며 점점 더 복잡하고, 큰 프로덕트들이 생성되고, 개발자 혼자서 모든 것을 감당하기에는

더욱 많아진 유저와 많아진 요구사항, 개발 환경으로 인해서 협업과 유지보수의 중요성이 강조되어 가고 있다.

 

그렇다 보니 우리의 선배님들께서는 많은 고민을 하셨고, 객체지향, 함수형 프로그래밍부터 MVC, MVVM 그리고 아키텍처까지 여러 패러다임과 구성들이 나왔다고 생각한다.

 

누가 봐도 알아볼 수 있는 약속이 필요했고, 내가 아니어도 함께 코드를 작성할 수 있어야 했으며

나도 남의 코드를 수정, 확장할 수 있어야 하고, 남도 나의 코드를 수정, 확장할 수 있어야 했기 때문이다.

 

일단 오늘의 주제인 클린아키텍처와 구글 권장 아키텍처도 이러한 과정 속에서 탄생했다고 생각한다.

 

아키텍처란 각 계층 간의 관심사의 분리를 통해서 기능을 수정하거나 보안에 자유로워지고,

유지 보수도 유리해지는 앱을 만들기 위한 구조라고 말할 수 있을 거 같다.

 

클린 아키텍처 vs 구글 권장 아키텍쳐

 

이 두 가지는 혼동이 많이 일어나는 부분이다 나도 얼마 전까지 둘의 차이를 크게 느끼지 못했고, 비슷한 거 아닌가? 하고 넘어갔다가 큰 코를 다치고 다시 공부를 해보았다

 

간단하게 말하면 목적은 같지만 차이가 있다.

구글 권장 아키텍처의 경우 조금 더 앱 개발을 위한 쪽으로 발전된 느낌이고,

클린 아키텍처의 경우 다른 플랫폼까지 고려한 느낌을 받았다.

 

아래에 설명을 하겠지만 구글 권장 아키텍처는 도메인 레이어가 데이터 레이어를 알고 있지만 클린아키텍처에서는 도메인 레이어가 데이터 레이어를 알지 못하는 구조이다.

 

또한 클린 아키텍처에서 도메인 레이어는 필수이지만 구글 권장 앱아키텍처에서는 선택사항이다.

 

1. 권장 - 앱개발에 치중, 클린 - 모든 플랫폼을 고려

2. 권장 - 도메인 레이어가 데이터 레이어를 알고 있다, 클린 - 도메인 레이어는 데이터 레이어를 알면 안 된다.

3. 권장 - 도메인 레이어는 선택, 클린 - 도메인 레이어 필수

 

클린 아키텍처

 

클린 아키텍처를 검색하면 바로 나오는 그림이다.

이 그림으로 클린 아키텍처의 구성을 이해할 수 있다.

 

여기서 중요한 부분은 의존성이 밖에 원에서 안쪽으로 들어가고 원의 안쪽은 밖을 알면 안 된다.

 

그리고 이 다이어그램을 안드로이드개발에 맞게 레이어를 나누어 보면

 

 

이런 형태로 레이어가 나누어지게 된다.

그러면 자연스럽게 프레젠테이션 레이어 -> 도메인 레이어로 의존성이 흘러가고 도메인 레이어는 데이터 레이어를 알면 안 된다고 하였으니 어떻게 하지?라는 생각이 들게 된다.

 

여기서 사용되는 개념이 의존성 역전의 원칙이다.

클린 아키텍처의 특징은 Repository의 인터페이스는 도메인 레이어에 속하고, Repository의 구현체는 데이터 레이어라는 점이다.

그래서 메서드 의존성을 제거하고 추상화에 의존하게 만드는 의존성 역전의 원칙을 적용할 수 있게 되어 도메인 레이어가 데이터 레이어를 모르는 상황을 연출할 수 있다.

 

프레젠테이션 레이어

 

UI와 ViewModel, MVP를 사용한다면 Presenter가 포함되는 레이어다

UI 관련된 부분들이 존재하고, UseCase를 뷰모델에 주입받아서 코드를 처리하게 된다.

안드로이드 개발을 한다면 안드로이드 종속성이 높아지게 되는 레이어

 

도메인 레이어

 

UseCase, Entity가 포함되는 레이어로 여러 애플리케이션에서 사용될만한 전사적인 규칙과 객체, 메서드가 들어있는 부분으로

안드로이드 같은 프레임 워크에 종속성이 포함되면 안 되는 부분이다.

Traslator를 통해서 데이터 레이어에서 받아온 DTO 같은 데이터들을 도메인에서 사용할 데이터로 변경해서 받아오거나 레파지토리의 인터페이스로 전달한다.

(DTO가 변경되더라도 도메인에서 사용할 데이터가 확정이 되어있다면 정말 싹 바뀌지 않는 이상 적은 공수만으로도 대응이 가능해진다)

 

데이터 레이어

 

DB나 API를 통해서 데이터를 받아오는 작업을 하는 부분이다.

retrofit, Room, repository의 구현체, dataStore 등의 코드들이 자리하게 되는 부분이다.

 

구글 권장 아키텍처

 

 

 

구글 권장 아키텍처 가이드에 들어가면 구글에서 제시한 그림이다.

구글 권장 아키텍처의 구성 자체는 클린타키텍처에서 설명한 부분과 같다.

 

하지만 화살표를 보면 구글 권장 아키텍처에서는 도메인 레이어가 데이터레이어를 알고 있고, 도메인 레이어가 선택사항이다.

 

그렇기 때문에 유즈케이스를 사용하지 않고 ViewModel -> Repository 같은 형식으로 넘어가도 괜찮게 되는 것이다.

 

장단점

  • 구글 권장 아키텍처
    • 장점
      • 클린 아키텍처보다 훨신 간단하고, 자유도가 높다
      • 작성해야하는 코드양이 줄어든다.
      • 러닝커브가 비교적 낮다
    • 단점
      • 유지보수, 테스트시 어떻게 작성했느냐에 따라서 비교적 힘들어질 수 있다.
      • 앱의 규모가 커진다면 오히려 복잡한 코드들이 양성될 수 있다.
      • 안드로이드 의존성이 비교적 높아 질 수 있어서 KMM 같은 기술을 사용할때 제약이 생기거나 수정이 많이 필요할 수 있다.

 

  • 클린 아키텍쳐
    • 장점
      • 객체지향 원칙을 잘 따른 구조이다.
      • 테스트가 용이하고, 유지보수가 유리하다.
      • 앱의 규모가 커지고 개발자의 수가 많다면 오히려 좋을 수 있다고 생각된다.
      • 프레젠테이션 레이어만 잘 나누어 주면 KMM 같은 기술을 사용할 때 유리해 보인다.
    • 단점
      • 러닝커브가 높고, 설계 시 고민할 것들이 많다. (유즈케이스의 구성, 매퍼의 유무 등등)
      • 작성할 코드의 양이 늘어난다.
      • 앱의 규모가 그렇게 크지 않다면 오히려 가독성이 떨어질 수 있을 거 같다.