[Android App Architecture] Intro

💡해당 글은 앱 아키텍처 가이드를 이해하기 쉽게 정리한 글입니다.

좋은 아키텍처란 무엇일까요?

필자는 본인의 앱이 해결해야하는 문제들에 가장 적합한 아키텍처라고 생각합니다.
또한 코드가 어디에서/어떻게 동작 할지 이해하고 예측하기 쉬워야하죠.

"어떻게하면 좋은 아키텍처로 짤 수 있을까?"를 검색하다 보면 다음과 같은 개념들을 접하게됩니다.

• Clean Architecture

  개발자들이라면 모두 한번쯤 본 그 과녁판.

• MVVM (+Repository)

  MVC MVP MVI와 함께 많이 쓰이는 아키텍처 패턴

이러한 내용들은 자료가 방대하기 때문에 여기에서는 따로 설명하지 않도록 하겠습니다.
그렇다면 이러한 개념들을 안드로이드에서는 어떻게 적용해햐할까요?
사실 정답은 존재하지 않습니다.
회사마다 앱의 기능이 다르고 개발자들의 생각이나 스타일도 제각각이니까요.

"그렇다면 우리는 이러한 아키텍처를 어떻게 공부해야 할까요?"

필자의 경우 이 문서를 통해 질문에 대한 답을 얻을 수 있었습니다.

해당 글은 안드로이드 공식문서의 앱 아키텍처 가이드 개요를 이해하기 쉽게 정리한 글입니다.

---

핵심 원칙

관심사의 분리

Activity와 Fragment는 최대한 가볍게 유지해야하며 UI Logic만을 포함해야 합니다.
또한 Context를 사용하는 코드는 모두 여기에서 처리되어야 합니다.

• UI Logic : 특정 이벤트나 상태에 따라 UI를 어떻게 보여줄지에 대한 로직

데이터 모델에서 UI 도출하기

Room, DataStore와 같은 곳에 저장되는 지속적인 데이터를 기반으로 UI를 구성해야합니다.

여기에서 설명하는 지속적인 데이터는 ViewModel에 저장된 데이터(상태라고 표현합니다.)가 아닌 앱을 종료해도 저장되는 데이터입니다.

단일 소스 저장소 (SSOT)

특정 유형 데이터의 모든 변경사항은 한 곳에서 처리해야합니다.

이를 통해 본인이 짠 코드가 아니더라도 데이터의 변경이 어디에서 일어날지 예측할 수 있게됩니다.

단방향 데이터 흐름 (UDF)

상태 : Repository -> ViewModel -> View 방향으로만 전달해야합니다.
이벤트 : View -> ViewModel -> Repository 방향으로만 전달해야합니다.

이러한 일관성으로 인해 코드가 어디에서/어떻게 동작 할지 예측할 수 있게됩니다.

---

권장 앱 아키텍처

UI Layer

상태를 기반으로 UI를 표시하는 영역

사용자와의 상호작용(ex. 클릭 이벤트)과 상태 변경에 따라 UI가 자동으로 업데이트 되어야합니다.
UI는 다음과 같은 두 가지로 구성됩니다.

• UI Elements : XML or Jetpack Compose, Activity, Fragment
• State Holder : ViewModel

Activity와 Fragment는 UI Logic을 처리할때 UI Controller라고도 불립니다.
ViewModel은 UI에 사용될 상태를 가지고 있고 이벤트에 대한 로직을 처리합니다.

이벤트에 대한 로직은 클릭 이벤트와 같은 상황에 수행해야할 비즈니스 로직을 적절한 저장소 클래스에 위임하는 것입니다.

혹은 여기에서 비즈니스 로직을 처리하는 설계를 할 수도 있습니다. 이 경우 Repository는 단순히 데이터 소스들을 모아놓은 저장소의 역활만을 수행합니다.

Data Layer

Business Logic을 처리하는 영역

• Business Logic : 지속적인 데이터를 어떻게 처리해야 할지에 대한 로직

앱에서 처리하는 다양한 유형의 데이터별로 Repository를 만들어 사용해야합니다.
Repository는 파일, 네트워크, 로컬 데이터베이스와 같은 DataSource들을 한 곳으로 모아 관리하는 저장소 클래스입니다.

Domain Layer

UI Layer와 Data Layer 사이에 있는 영역

복잡한 비즈니스 로직이나 여러 ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당합니다.
필요한 경우 선택적으로 사용할 수 있습니다.

해당 레이어들의 자세한 설명은 다음 글에서 부터 순차적으로 다루겠습니다.

의존성 주입 (DI)

의존성 주입은 관련 라이브러리를 사용하거나 서비스 로케이터 패턴으로 직접 구현 가능합니다.
Hilt Dagger Koin 등이 있으며 공식문서에서는 Hilt의 사용을 권장하고 있습니다.

추가 권장사항

아래의 목록은 공식문서에서 권장하는 사항들입니다.

• 상태는 Activity와 Fragment가 아닌 ViewModel에서 가지고있는 것이 좋습니다.
• Activity와 Fragment는 Context를 사용하는 유일한 클래스여야만합니다. (+ 4대 컴포넌트)
• 책임이 잘 정의된 경계를 만드는 것이 좋습니다. (어려울 수도 있는 개념입니다.)
  ex) 네트워크에서 데이터를 가져오는 코드를 여러 클래스에 분산시키면 안됩니다.
  ex) 여러 개의 관련 없는 책임을 하나의 클래스에 정의하면 안됩니다.
• Jetpack 라이브러리와 기타 권장 라이브러리를 사용하도록합니다.
• 오프라인 우선 앱 : 가능한한 최신의 데이터를 로컬에 보존합니다.
  이렇게하면 기기가 오프라인일 때도 사용자가 앱의 기능을 이용할 수 있습니다.

참고하면 좋은 자료

https://developer.android.com/topic/architecture?hl=ko
https://developer.android.com/courses/android-basics-kotlin/course
https://github.com/android/sunflower/tree/main
https://fastcampus.co.kr/dev_red_ksr