Architecture 구조도 (이론편 - UI 레이어)

먼저 들어가기 앞서 내가 생각하는 아키텍쳐 구조도는 다음과 같다.

위의 그림에 대해 정리해 보면 아래와 같다.

이번 편은 UI레이어에 대한 설명과 나의 생각을 작성해 보겠다.

---

사용자 상호작용(예: 버튼 누르기) 또는 외부 입력(예: 네트워크 응답)으로 인해 데이터가 변할 때마다 변경사항을 반영하도록 UI가 업데이트되어야 합니다. 사실상 UI는 데이터 레이어에서 가져온 애플리케이션 상태를 시각적으로 나타난다.

아래의 사진과 같이 UI레이어는 UI element 와 State holder 가 합쳐진 형태이고 Data 레이어(or Domain 레이어)에 의존한다.

 

UI 레이어 구현 방법

UI라는 용어는 UI라는 용어는 사용하는 API(뷰 또는 Jetpack Compose)와 관계없이 데이터를 표시하는 활동 및 프래그먼트와 같은 UI 요소를 가리킨다.

구글 아키텍쳐 가이드에서는 UI 레이어를 구현하는 방법을 4가지로 제시한다.

• UI 상태를 정의하는 방법
• UI 상태를 생성하고 관리하기 위한 단방향 데이터 흐름(UDF)
• UDF 원칙에 따라 관찰 가능한 데이터 유형으로 UI 상태를 노출하는 방법
• 관찰 가능한 UI 상태를 사용하는 UI를 구현하는 방법

UI 상태 정의

위의 그림과 같이 UI는 UI Element + UI State 이다.

그 중 UI State 는 앱에서 사용자에게 표시하는 정보 이다.

단방향 데이터 흐름으로 상태 관리

UI는 Data를 State에 맞춰 이벤트에 적용할 비지니스 로직 을 정의하고 제작해 UI 동작 로직에 적용해야 한다.

그러기 위해서는 로직을 짜야하는데 Activity나 Fragment에 작성할 경우 UI에 부담을 주게된다. 또한 양향이 이루어 질 경우 테스트 등 많은 영향을 끼치게 된다. 그러므로 Viewmodel을 제작하여 단방향으로 흐르게 하고 Activity와 Fragment는 UI 로직만 수행하여 UI의 부담을 줄여준다.

추가적으로 비지니스 로직은 Damain 레이어을 추가하여 Domain 레이어가 맡게 한다면 ViewModel은 Domain 레이어와 연결하는 연결고리가 되어 더욱 커플링을 끊어내게 된다.

아래 사진은 ViewModel을 추가한 Date레이어와 UI 레이어의 연결 그림이다.

ViewModel의 역할은 다음과 같습니다.

• ViewModel이 UI에 사용될 상태를 보유하고 노출한다. UI 상태는 ViewModel에 의해 변환된 애플리케이션 데이터이다.
• UI가 ViewModel에 사용자 이벤트를 알린다.
• ViewModel이 사용자 작업을 처리하고 상태를 업데이트한다.
• 업데이트된 상태가 렌더링할 UI에 다시 제공된다. 상태 변경을 야기하는 모든 이벤트에 위의 작업이 반복된다.

최종적으로 아래와 같은 이점을 얻게 됩니다.

• 데이터 일관성: UI용 정보 소스가 하나이다.
• 테스트 가능성: 상태 소스가 분리되므로 UI와 별개로 테스트할 수 있다.
• 유지 관리성: 상태 변경은 잘 정의된 패턴을 따른다. 즉, 변경은 사용자 이벤트 및 데이터를 가져온 소스 모두의 영향을 받는다.

---

인민군의 의견

위의 내용은 구글 앱 아키텍쳐의 내용을 내가 이해할 수 있게 정리해 놓은 것이다.

그런데 위의 내용들을 읽다보면 이것이 완벽한 MVVM의 방식이냐? 라는 의문이다.

결론부터 말하자면 MVVM =! Google App Architecture
둘은 정의가 다르다는 것이다!(뭐 애초에 패턴과 아키텍쳐를 비교하는게 이상한 말이지만...)

내가 이해한 MVVM의 ViewModel은 DomainLayer에 가깝다. 그림으로 표현하자면 아래와 같다.

그래서 MVVM의 ViewModel은 프레임워크에 종속되지 않도록 Kotlin이나 Java로만 작성되어 있다.
그러나 구글에서 제공하는 Jectpack - ViewModel을 사용한다는 것 자체가 ViewModel이 프레임워크에 종속되어 있어 성립되지 않는다.

우리의