모바일 앱 사용자 환경
일반적인 Android 앱은 여러 구성요소를 포함할 수 있고, 사용자는 짧은 시간 내에 여러 앱과 상호작용할 때가 많다는 점을 고려하면, 앱은 사용자 중심의 다양한 워크플로 및 작업에 맞게 조정될 수 있어야한다.
앱 구성요소는 개별적이고 비순차적으로 실행될 수 있으며, 운영체제나 사용자가 언제든지 앱 구성요소를 소멸시킬 수 있다. 이러한 이벤트는 직접 제어할 수 없기때문에 앱 구성요소에 애플리케이션 데이터나 상태를 저장해서는 안되고, 앱 구성요소가 서로 종속되면 안된다.
일반 아키텍처 원칙
Android 앱은 크기가 커지기 때문에 앱을 확장하고 앱의 견고성을 높이며 앱을 더 쉽게 테스트할 수 있도록 아키텍처를 정의하는 것이 중요하다.
관심사 분리
처음 안드로이드를 시작했다면, Activity나 Fragment에 모든 코드를 작성하기도 한다. (내가 그러했듯이..) UI 기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함해야 한다.
💡 UI 기반의 클래스는 최대한 가볍게 유지하기운영체제는 사용자 상호작용을 기반으로 또는 메모리 부족과 같은 시스템 조건으로 인해서 언제든지 클래스를 소멸시킬 수 있다.
→ 그러므로, UI 클래스에 대한 의존성을 최소화하는 것이 중요하다
데이터 모델에서 UI 도출하기
데이터 모델은 앱의 데이터를 나타낸다. 이 모델은UI 요소 및 기타 구성요소로부터 독립되어 있다. UI 앱 구성요소 수명주기와는 관련이 없다.
UI 모델은 가급적 지속적인 모델을 권장하는데 그 이유는 Android 운영체제에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않는 다는 점, 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동한다는 점이다.
단일 소스 저장소
앱에서 새로운 데이터 유형을 정의할 때는 데이터 유형에 단일 소스 저장소 SSOT(Single Source of Truth)를 할당해야 한다.
SSOT는
- 데이터의 소유자이다
- SSOT만 데이터를 수정하거나 변경할 수 있다.
- 불변 유형을 사용해서 데이터를 노출한다.
- 다른 유형이 호출할 수 있는 이벤트를 수신하거나 함수를 노출해서 데이터를 수정한다
덕분에, 특정 유형 데이터의 모든 변경사항을 한 곳에서 확인할 수 있고 다른 유형이 조작할 수 없도록 데이터를 보호한다는 장점이 있다. 데이터 변경사항을 더 쉽게 추적할 수 있게 하여 버그를 발견하기 쉽다.
단방향 데이터 흐름
SSOT는 Google 가이드에서 종종 단방향 데이터 흐름 UDF (Unidirectional Data Flow)패턴과 함께 사용된다.
💡 UDF에서 상태는 한 방향으로 흐르고 데이터를 수정하는 이벤트는 반대 방향으로 흐른다.예를 들어, 버튼을 누르는 것과 같은 사용자 이벤트는 UI → SSOT로 흐른다.
→ 데이터 일관성을 강화하고, 디버그하기 쉽다.
권장 앱 아키텍처
각 애플리케이션에는 최소 두가지 레이어가 포함되어야 한다.
- UI Layer
- Data Layer
이 화살표들은 모듈들 간의 의존관계를 뜻한다.
Domain Layer는 써있는 것처럼 optional이다. UI와 데이터 레이어 간의 상호작용을 간소화하고 재사용하기 위해 쓰인다. 이후 자세히 다뤄보기로 하자.
위에서 알아본 단방향 데이터 흐름과 위 그림을 연결해보면 단방향 데이터 흐름에는 2가지 방식이 있다. Up Stream 방식과 Down Stream 방식이다.
- Up Stream
ex) 사용자의 클릭 이벤트
UI → Domain → Data (상위 레이어로 전달)
- Down Stream
ex) Remote 또는 서버로부터 받은 Data → Domain → UI (하위 레이어로 전달)
UI 레이어
( = presentation Layer라고도 불린다 )
화면에 애플리케이션 데이터를 표시하는 것이다.
사용자 상호작용, 외부입력으로 인해 데이터가 변할 때마다 변경사항을 반영하도록 UI가 업데이트 되어야 한다.
데이터 레이어
앱의 데이터 레이어에는 비지니스 로직이 포함되어있다.
비지니스 로직이란, 앱의 가치를 부여하는 요소로 앱의 데이터 생성, 저장, 변경 방식을 결정하는 규칙으로 구성된다.
데이터 레이어는 0개부터 데이터 소스를 포함할 수 있는 저장소로 구성된다. 앱에서 데이터를 처리하는 다양한 유형별로 저장소 클래스를 만든다. (각 유형별로 맞는 데이터 클래스가 생긴다는 것)
예를 들어, 영화 관련 데이터에는 MoviesRepository를 결제 관련 데이터는 PaymentRepository 클래스를 만들 수 있다.
여기서 Data Source와 Repositories의 관계를 살펴보자
Repository
- 앱에서 필요한 데이터를 DataSource에 요청하는 책임
- Data Source로부터 받아온 데이터를 새로운 모델로 가공하여 하위 레이어 Domain/UI에 전달하는 책임
- 가공한 데이터를 Repostory 모듈에 캐싱하는 책임
옷 주문이 들어왔을 때, DataSource에 옷을 만들기 위해 필요한 실과 바늘을 요청한다.
Data Source
- Remote/Local Server에게 데이터를 요청한다
- Repository로 데이터를 제공한다
이후 각 공장에서 실과 바늘을 받아 옷 공장에서 옷을 만든다.
이 과정이 데이터 가공이고, 이를 하위 레이어에게 제공까지 한다.
즉, DataSource는 서버로부터 받은 데이터를 Repository로 보내고 Repository는 받은 데이터를 가공하여 하위 레이어로 보내주는 역할을 한다.
도메인 레이어
아까 말했던 선택적 레이어이다.
도메인 레이어는 복잡한 비지니스 로직이나 여러 ViewModel에서 재사용되는 간단한 비지니스 로직의 캡슐화를 담당한다. 필수적은 것은 아니나 복잡성을 처리하거나 재사용성을 선호하는 등 필요한 경우에 도메인 레이어를 사용하면 좋다고 한다.
