먼저 이 포스터를 읽기 전 Architecture Patten 파트를 읽어보면 정말 너무 많은 개발 아키텍쳐가 있습니다.

저 또한 MVC -> MVP -> MVVM -> MVI 라는 이론자료를 통해 학습을 했지만 너무나도 중구난방의 오픈소스에 갈피를 잡지 못했습니다.

그러던중 구글에서 앱 아키텍쳐 가이드라는 포스터로 가이드를 정의해 주었습니다.(쫌더 일찍 알았다면 헷갈리지 않았을텐데...)

확실한건 MVVM == 구글 앱 아키텍쳐 가이드 는 아닌가 봅니다. 아래사진과 같이 구글에서도 유사하다 했지 똑같다고 안한듯.....

위의 포스터에서는 "서로간(각 경계간)의 종속을 없애고, 제어 흐름을 지키는 것" 이라 합니다.

그중 구글 아키텍쳐 컴포넌트(AAC) 를 이용한다면 쉽게 접근이 가능하다 합니다.

그렇다면 "서로간(각 경계간)의 종속을 없애고, 제어 흐름을 지키는 것" 을 어떻게 하는것일까요?

첫번째로 바로 관심사의 분리 입니다.

흔히 하는 실수인 Activity와 Fragment에 모든 코드를 작성하는것인데 이들은 소유 대상이 아니며 Android OS와 앱 사이의 계약을 나타내도록 이어주는 클래스일 뿐입니다. OS는 사용자 상호작용을 기반으로 또는 메모리 부족과 같은 시스템 조건으로 인해 언제든지 클래스를 제거될 수 있습니다.

두번쨰로 데이터 모델에서 UI 도출하기 입니다.

가급적 지속적인 모델을 권장합니다. 데이터 모델은 앱의 데이터를 나타냅니다. 이들은 앱의 UI 요소 및 기타 구성요소와 독립되어 있습니다. 즉, 이들은 UI 및 앱 구성요소 수명 주기와는 관련이 없습니다. 하지만 OS에서 메모리에서 앱의 프로세스를 삭제하기로 결정하면 여전히 삭제됩니다.

지속 모델이 이상적인 이유는 다음과 같습니다.

• Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않습니다.
• 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동합니다.

위와 같은 그림을 볼 수 있을것입니다.

MVVM의 형태와 비슷합니다.

이 포스터에서는 위에 그림의 형태보다는 아래와 같은 그림의 설명으로 구조화 할 것을 권장합니다.

이전 섹션에서 언급된 일반적인 아키텍처 원칙을 고려하여 각 애플리케이션에는 레이어가 두 개 이상 있어야 합니다.

• 화면에 애플리케이션 데이터를 표시하는 UI 레이어
• 앱의 비즈니스 로직을 포함하고 애플리케이션 데이터를 노출하는 데이터 레이어 UI와 데이터 레이어 간의 상호작용을 간소화하고 재사용하기 위한 도메인 레이어라는 레이어를 추가할 수 있습니다.

참고로 도메인 레이어는 옵션 사항입니다.

반드시 종속되는 방향은 위에서 아래여야 합니다.(절대 반대쪽에서는 자신을 사용하는쪽을 몰라야 하며 불러올 수 도 없습니다.)

해당 링크들은 직접 제작한 Hilt를 사용한 ToDo 프로젝트로 예시를 든 내용입니다.

앱의 클래스는 올바른 작동을 위해 다른 클래스에 종속됩니다. 그러기 위해서는 종속적 항목 주입(DI)를 사용합니다.

그중 Hilt 라이브러리를 추천합니다.