앱 아키텍처 - 챌린지 과제

모바일 앱 사용자 환경

일반적으로 Android 앱에는 여러 앱 구성요소가 포함되는데, 앱 구성요소는 개별적이고 비순차적으로 실행될 수 있다. 운영체제나 사용자가 언제든지 앱 구성요소를 소멸시킬 수 있는데, 이런 이벤트는 직접 제어할 수 없기 때문에 

앱 구성요소에 애플리케이션 데이터나 상태를 저장해서는 안 되며 앱 구성요소가 서로 종속되면 안된다.

 

 

일반 아키텍처 원칙

안드로이드 앱에 있어 아키텍처를 정의하는 것은 중요하다. 앱 아키텍처는 앱의 부분과 그 각 부분에 필요한 기능 간의 경계를 정의한다. 애플리케이션 데이터나 상태를 저장하는데 앱 구성요소를 사용할 수 없는 요구사항을 충족하려면 몇 가지 특정 원칙을 준수하도록 앱 아키텍처를 설계해야한다. 

관심사 분리

Activity 또는 Fragement 같은 UI 기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함해야 한다. 왜냐하면 이들은 소유 대상이 아니며 Android OS와 앱 사이의 계약을 나타내도록 이어주는 클래스일 뿐이다. OS는 사용자 상호작용을 기반으로 시스템 조건으로 인해 언제든지 클래스를 소멸시킬 수 있다는 점을 고려해볼때, 이러한 클래스들에 대한 의존성을 최소화해야한다.

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

데이터 모델에서 UI를 도출해야 한다. 데이터 모델은 앱의 데이터를 나타내는데, 앱의 UI 요소 및 기타 구성요소로부터 독립되어 있다. 즉, 데이터 모델은 UI 및 구성요소 수명 주기와 관련이 없다. 하지만 OS가 앱의 프로세스를 삭제하면 데이터 모델도 삭제된다. 데이터 모델 클래스를 기반으로 앱 아키텍처를 구축하는 것이 좋다.

단일 소스 저장소(SSOT)

앱에서 새로운 데이터 유형을 정의할 때는 데이터 유형에 단일 소스 저장소(SSOT)를 할당해야 한다. SSOT는 데이터의 소유자이며, SSOT만 데이터를 수정하거나 변경할 수 있다. 또한, 애플리케이션의 데이터 정보 소스는 주로 데이터베이스이다.

2.4 단방향 데이터 흐름(UDF)

UDF에서 상태는 한 방향으로만 흐른다. Android에서 상태 또는 데이터는 일반적으로 계층 구조의 상위 범위 유형에서 하위 범위 유형으로 흐른다. 하지만, 데이터를 수정하는 이벤트는 보통 하위 범위 유형에서 발생되어 상응하는 데이터 유형의 SSOT에 도달한다.(=이벤트는 반대 방향으로 흐른다.) 예를 들어, 데이터는 보통 데이터 소스(상위)에서 UI(하위)로 흐른다. 버튼 누르기 같은 사용자 이벤트는 UI(하위)에서 SSOT로 흐르며, SSOT에서는 데이터가 불변 유형으로 수정 및 노출된다.

 

 

권장 앱 아키텍처

화면에 애플리케이션 데이터를 표시하는 UI 레이어, 앱의 비즈니스 로직을 포함하고 애플리케이션 데이터를 노출하는 데이터 레이어는 반드시 포함되어야 한다. UI와 데이터 레이어 간의 상호작용을 간소화하고 재사용하기 위한 목적으로 사용하는 도메인 레이어는 선택적 사항이다.

애플리케이션의 레이어

UI 레이어

화면에 애플리케이션 데이터를 표시한다. 사용자 상호작용(예: 버튼 누르기) 또는 외부 입력(예: 네트워크 응답)으로 인해 데이터가 변할 때마다 변경사항을 반영하도록 UI가 업데이트되어야 한다. 두가지로 구성된다.

- UI elements : 화면에 데이터를 렌더링하며, View 또는 Jetpack Compose 함수를 사용해 빌드할 수 있다.

- State holders : 데이터를 보유하고 이를 UI에 노출하며 로직을 처리한다. 예로는 ViewModel 클래스가 있다.

UI 레이어

데이터 레이어

데이터 레이어에는 비즈니스 로직이 포함된다. 데이터 레이어는 여러 개의 데이터 소스를 각각 포함할 수 있는 저장소로 구성된다. 앱에서 처리하는 다양한 유형의 데이터별로 저장소 클래스를 만들어야 한다. 예를 들어 영화 관련 데이터는 MoviesRepository 클래스를 만들거나 결제 관련 데이터에는 PaymentsRepository 클래스를 만들 수 있다. 각 데이터 소스 클래스는 하나의 데이터 소스만 사용해야 한다.

데이터 레이어

도메인 레이어

복잡한 비즈니스 로직이나 여러 ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당한다. 복잡성을 처리하거나 재사용성을 선호하는 등 필요한 경우에만 사용한다. 해당 레이어의 클래스는 일반적으로 사용 사례 또는 상호작용자라고 한다. 

구성요소 간 종속 항목 관리

- 종속 항목 주입(DI) : 클래스가 자신의 종속 항목을 구성할 필요 없이 종속 항목을 정의할 수 있다. 런타임 시 다른 클래스가 이 종속 항목을 제공해야 한다.

- 서비스 로케이터 : 클래스가 자신의 종속 항목을 구성하는 대신 종속 항목을 가져올 수 있는 레지스트리를 제공한다.

종속 항목 삽입 패턴을 따르고 Android 앱에서 Hilt 라이브러리를 사용하는 것이 좋다.

 

 

일반 권장사항

앱 구성요소에 데이터를 저장한다.

앱 구성요소는 사용자와 기기의 상호작용 및 시스템의 전반적인 현재 상태에 따라 단기간만 지속된다.

엡 구성요소는 Context 또는 Toast 같은 Android 프레임워크 SDK API를 사용하는 유일한 클래스여야 한다.

 

앱의 다양한 모듈 간 책임이 잘 정의된 경계를 만든다.

네트워크에서 데이터를 로드하는 코드를 코드베이스의 여러 클래스나 패키지 전체에 분산하면 안된다.

 

각 모듈에서 가능하면 적게 노출한다.

 

다른 앱과 차별되도록 앱의 고유한 핵심에 초점을 맞춥니다.

동일한 상용구 코드를 반복하여 작성하느라 시간을 낭비하지 말자. 대신 앱을 독특하게 만드는 데 시간과 에너지를 집중하고 반복적인 상용구는 Jetpack 라이브러리 등 에 처리하도록 하자.

 

앱의 각 부분을 독립적으로 테스트하는 방법을 고려하자.

예를 들어 네트워크에서 데이터를 가져오기 위해 API를 잘 정의하면 해당 데이터를 로컬 데이터베이스에 보존하는 모듈을 더 쉽게 테스트할 수 있습니다. 그러지 않고 두 모듈의 로직을 한 위치에 혼합하거나, 네트워크 코드를 전체 코드베이스에 분산하면 테스트가 불가능하지는 않을지라도 훨씬 더 어려워진다.

 

아키텍처의 이점

앱에 좋은 아키텍처를 구현하는 것이 좋다. 아키텍처에 투자하는 것은 중요하다. 하지만, 아키텍처에는 초기에 투자하는 시간이 필요하다.