[Android] 앱 아키텍처 가이드 (1)
- 불필요한 코드나 잘못 작성된 내용에 대한 지적은 언제나 환영합니다. 👍
- Android developers의 앱 아키텍처 가이드 문서를 핵심 요약 정리 및 한글에 더 자연스러운 문맥으로 번역 작성한 글입니다.
일반 아키텍처 원칙
안드로이드 앱이 점점 커짐에 따라 앱을 확장하기 쉽고, 견고하며, 테스트하기 쉬운 아키텍처를 정의하는 것이 중요하다.
앱 아키텍처는 앱의 여러 파트들간의 경계와 각각의 파트가 가질 역할을 정의한다.
이를 충족하기 위해서 특정 원칙을 따라 앱 아키텍처를 디자인해야 한다.
1. 관심사 분리 (Separation of concerns)
가장 중요한 원칙!
액티비티(Activity)나 프래그먼트(Fragment)와 같은 UI 기반의 클래스는 UI와 운영 체제와의 상호작용을 처리하는 로직만 포함해야 한다.
이러한 클래스를 최대한 간결하게 유지함으로써, 컴포넌트의 라이프사이클 관련 문제를 피하면서 테스트도 수월하게 가능하다.
만족스러운 사용자 환경과 더욱 수월한 앱 관리 환경을 제공하려면 이러한 클래스에 대한 의존성을 최소화하는 것이 좋다.
2. 데이터 모델로부터 UI 도출하기 (Drive UI from data models)
또 하나의 중요한 원칙은 데이터 모델에서 UI를 도출해야 한다는 것이다. (persistent models 권장)
데이터 모델은 앱의 데이터를 나타내며, UI 요소나 앱의 다른 컴포넌트와 독립적이다. (UI나 앱 컴포넌트의 라이프사이클에 의존하지 않음)
데이터 모델 클래스를 기반으로 앱 아키텍처를 구축하면, 앱이 더 견고해지고 테스트를 하기 쉬워진다.
지속 모델(persistent models)이 적합한 이유
- Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않음
- 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동함
3. 단일 소스 저장소 (Single source of truth, SSOT)
앱에서 새로운 데이터 유형을 정의할 때는 데이터 유형에 단일 소스 저장소(SSOT)를 할당해야 한다.
SSOT는 데이터의 소유자이며, SSOT만 데이터를 수정하거나 변경할 수 있다.
SSOT는 이를 위해 불변(immutable) 유형을 사용하여 데이터를 노출하며, 다른 유형이 호출할 수 있는 이벤트를 수신하거나 함수를 노출하여 데이터를 수정한다.
SSOT 패턴의 장점
- 특정 유형의 데이터에 대한 모든 변경 사항을 한 곳에 집중시킴
- 다른 유형이 조작할 수 없도록 데이터를 보호
- 데이터 변경사항을 더 쉽게 추적할 수 있도록 하여, 디버깅이 수월해짐
4. 단방향 데이터 흐름(Unidirectional Data Flow)
단일 소스 저장소(SSOT) 원칙은 Google 가이드에서 종종 단방향 데이터 흐름(UDF) 패턴과 함께 사용된다.
UDF에서 State는 한 방향으로만 흐르며, 데이터를 수정하는 Event는 반대 방향으로 흐른다.
안드로이드에서는 일반적으로 State나 Data가 위에서 아래로 흐른다. Event는 보통 아래쪽에서 트리거되어 SSOT까지 도달한다. 예를 들어, 애플리케이션 데이터는 데이터 소스에서 UI로 내려가고, 버튼 클릭과 같은 사용자 이벤트는 UI에서 SSOT로 올라가서, 애플리케이션 데이터가 수정된다.
이 패턴은 데이터가 일관되게 하고, 오류가 발생할 확률을 줄여 주며, 디버그하기 쉽고, SSOT 패턴의 모든 장점을 제공한다.
권장 앱 아키텍처
위에서 언급된 일반적인 아키텍처 원칙에 따라 각 애플리케이션에는 최소한 다음 두 가지 레이어가 포함되어야 한다.
- 화면에 애플리케이션 데이터를 표시하는 UI Layer
- 앱의 비즈니스 로직을 포함하고, 애플리케이션 데이터를 노출하는 Data Layer
선택적으로 Domain Layer를 추가하여, UI Layer와 데이터 Layer 사이의 상호작용을 간소화하고 재사용성을 높일 수 있다.
✏️ 참고 : 이 가이드의 다이어그램에서의 화살표는 클래스 간의 의존성을 나타낸다.
(ex: 도메인 레이어는 데이터 레이어 클래스에 의존함)
[Android] 앱 아키텍처 가이드(2) 에서 계속 이어집니다.