안드로이드 권장 아키텍처

앱 구성요소의 원칙

---

앱 구성요소는 개별적이고 비순차적으로 실행될 수 있으며, 운영체제나 사용자가 언제든지 앱 구성요소를 소멸시킬 수 있다. 이러한 이벤트는 직접 제어할 수 없으므로 앱 구성요소에 애플리케이션 데이터나 상태를 저장해서는 안되며 앱 구성요소가 서로 종속되면 안된다.

 

 

 앱 데이터와 상태를 저장하는 데 앱 구성요소를 사용할 수 없다면 앱을 어떻게 설계해야할까?



 

Android 앱은 크기가 커지기 때문에 앱을 확장하고 앱의 견고성을 높이며 앱을 더 쉽게 테스트할 수 있도록 아키텍처를 정의하는 것이 중요하다.

해당 사항들을 충족하려면 몇 가지 특정 원칙을 준수하도록 앱 아키텍처를 설계해야 한다.

관심사 분리	Activity 또는 Fragment에 모든 코드를 작성해서는 안된다. 이러한 UI기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함해야 한다. 최대한 가볍게 유지하여 구성요소 수명 주기와 관련된 많은 문제를 피하고그러한 클래스의 태스트 가능성을 개선한다. 만족스러운 사용자 환경과 더욱 수월한 앱 관리환경을 제공하기 위해 클래스에 대한 의존성을 최소화하는 것이 좋다.
데이터 모델에서 UI 도출	가급적 지속적인 모델을 권장 데이터 모델이란 앱의 데이터를 나타내며, 앱의 UI 요소 및 기타 구성요소로부터 독립되어 있다. 즉, 이들은 UI 및 앱 구성요소 수명 주기와는 관련이 없다. OS가 메모리에서 앱의 프로세스를 삭제하기로 결정하면 데이터 모델도 삭제된다. 지속 모델이 이상적인 이유는 Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않는 것과, 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동한다는 것이다. 데어터 모델 클래스를 기반으로 앱 아키텍처를 구축하면 앱의 테스트 가능성과 견고성이 더 높아진다.
단일 소스 저장소	앱에서 새로운 데이터 유형을 정의할 때는 데이터 유형에 단일 소스 저장소(SSOT)를 할당해야 한다. SSOT는 데이터의 소유자이며, SSOT만 데이터를 수정하거나 변경할 수 있고, 이를 위해 불변유형을 사용하여 데이터를 노출하며, 다른 유형이 호출할 수 있는 이벤트를 수신하거나 함수를 노출하여 데이터를 수정한다. 이 패턴에는 다음과 같은 장점이 있다. 1. 특정 유형 데이터의 모든 변경사항을 한곳으로 일원화 2. 다른 유형이 조작할 수 없도록 데이터를 보호 3. 데이터 변경사항을 더 쉽게 추적할 수 있도록 하고, 이로 인해 버그 발견이 쉬워짐 오프라인 중심 애플리케이션의 애플리케이션 데이터 정보 소스는 주로 데이터베이스이다. 다만, 정보 소스가 ViewModel 이거나 UI인 경우도 있다.
단방향 데이터 흐름	단일 소스 저장소 원칙은 Google 가이드에서 종종 단방향 데이터 흐름(UDF) 패턴과 함께 사용된다.  UDF에서 상태는 한 방향으로만 흐르고, 데이터를 수정하는 이벤트는 반대 방향으로 흐른다. Android에서 상태 또는 데이터는 일반적으로 계층 구조의 상위 범위 유형에서 하위 범위 유형으로 흐른다. 이벤트는 보통 하위 범위 유형에서 트리거되어 상응하는 데이터 유형의 SSOT에 도달한다. 예를 들어 애플리케이션 데이터는 보통 데이터 소스에서 UI로 흐르게 되고, 버튼 누르기와 같은 사용자 이벤트는 UI에서 SSOT로 흐르며, SSOT에서는 애플리케이션 데이터가 불변 유형으로 수정 및 노출된다. 이 패턴은 데이터 일관성을 강화하고, 오류 발생 확률을 줄여 주며, 디버그가 쉬워지고, SSOT 패턴의 모든 이점을 제공한다.

 

 

 

권장 앱 아키텍처

---

위에서 언급된 일반적인 아키텍처 원칙에 따라 각 애플리케이션에는 최소한 다음 두 가지 레이어가 포함되어야 한다.

 

1. 화면에 애플리케이션 데이터를 표시하는 UI 레이어

2. 앱의 비즈니스 로직을 포함하고 애플리케이션 데이터를 노출하는 데이터 레이어

 

UI, 데이터 레이어 간의 상호작용을 간소화하고 재사용하기 위한 도메인 레이어라는 레이어를 추가할 수 있다.

 

출처 : Android 공식문서

 

 

최신 앱 아키텍처 권장 사항

---

최신 앱 아키텍처에서는 다음 기법을 사용하도록 권장한다.

• 반응형 및 계층형 아키텍처
• 앱의 모든 레이어에서의 단방향 데이터 흐름 (UDF)
• 상태 홀더가 있는 UI 레이어로 UI의 복잡성 관리
• 코루틴 및 흐름
• 종속 항목 및 권장사항

 

 

UI 레이어

---

UI 레이어 (프레젠테이션 레이어)은 화면에 앱 데이터 표시이며, 사용자 상호작용 (버튼 누르기, 클릭) 또는 외부 입력 (네트워크 응답)으로 인해 데이터가 변할 때마다 변경사항을 반영하도록 업데이트되어야 한다.

 

UI레이어의 구성요소는 다음과 같다.

• 화면에 데이터를 렌더링하는 UI요소 (Jetpack Compose 함수)
• 데이터를 보유하고 이를 UI에 노출하며 로직을 처리하는 상태 홀더 (ViewModel)

출처 : Android 공식 문서

 

 

 

데이터 레이어

---

데이터 레이어에는 비즈니스 로직이 포함되어 있다. 비즈니스 로직이란 앱에 가치를 부여하는 요소로, 앱의 데이터 생성, 저장, 변경 방식을 결정하는 규칙으로 구성된다.

데이터 레이어는 여러 데이터 소스를 각각 포함할 수 있는 저장소로 구성된다. 앱에서 처리하는 다양한 유형의 데이터별로 저장소 클래스를 만들어야 한다. (Repository)

출처 : Android 공식 문서

 

저장소 클래스에서 담당하는 작업은 다음과 같다.

• 앱의 나머지 부분에 데이터 노출
• 데이터 변경사항을 한 곳에 집중
• 여러 데이터 소스 간의 충돌 해결
• 앱의 나머지 부분에서 데이터 소스 추상화
• 비즈니스 로직 포함

각 데이터 소스 클래스는 파일, 네트워크 소스, 로컬 데이터베이스와 같은 하나의 데이터 소스만 사용해야한다.

데이터 소스 클래스는 데이터 작업을 위해 애플리케이션과 시스템 간의 기교 역할을 한다.

 

 

도메인 레이어

---

도메인 레이어는 UI 레이어와 데이터 레이어 사이에 있는 선택적 레이어이다.

복잡한 비즈니스 로직이나 여러 ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당한다. 

복잡성을 처리하거나 재사용성을 선호하는 등 필요한 경우에만 도메인 레이어를 사용한다.

출처 : Android 공식 문서

 

이 레이어의 클래스는 일반적으로 사용 사례 또는 상호작용자라고 한다. 각 사용 사례는 하나의 기능을 담당해야하고, 해당 레이어는 Entity와 UseCase 등이 있다.

 

 

구성요소 간 종속 항목 관리

---

구성 요소 간 종속 항목 관리를 위해서는 Hilt 라이브러리의 사용을 권장한다.

 

 

일반 권장사항

---

1. 앱 구성요소에 데이터를 저장
2. Android 클래스의 종속 항목 줄이기
3. 앱의 다양한 모듈 간 책임이 잘 정의된 경계 형성
4. 각 모듈에서 가능하면 적게 노출
5. 다른 앱과 차별되도록 앱의 고유한 핵심에 초점 맞추기
6. 앱의 각 부분을 독립적으로 테스트하는 방법 고려
7. 유형은 동시 실행 정책을 담당
8. 가능한 한 관련성이 높은 최신 데이터를 보존

 

아키텍처의 이점

---

• 앱의 전반적인 유지관리성, 품질, 견고성 개선
• 앱을 확장할 수 있음 , 코드 충돌이 최소화되어 더 많은 인력과 팀이 동일한 코드베이스 기여 가능
• 온보딩에 도움이됨 , 프로젝트에 일관성을 부여하여 새로운 팀원이 빠르게 업무를 시작하고 짧은 시간에 고효율 작업이 가능
• 테스트 용이
• 버그를 체계적으로 조사

 

 

참고 문헌

---

앱 아키텍처 가이드  |  Android Developers