Android App Architecture (안드로이드 앱 아키텍처)

앱 아키텍처 가이드  |  Android 개발자  |  Android Developers

 

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

 

---

 

✔ 4가지의 일반 아키텍처 원칙

그래서 안드로이드의 앱은 견고성을 높이며 앱을 더 쉽게 테스트할 수 있도록 아키텍처를 정의하는 것이 중요하다. 

 

앱 아키텍처는 앱의 부분과 그 각 부분에 필요한 기능 간 경계를 정의한다. 이 말은 기능별로 앱이 잘 나누어져야 한다는 것이다.

 

관심사 분리 

관심사 분리는 이키텍처 원칙에서 가장 중요한 원칙이다. Activity나 Fragment 같은 UI 기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함해야 한다. 그러면 구성요소 구명 주기와 관련된 많은 문제를 피하고 테스트 가능성을 개선할 수 있다. 

OS는 사용자 상호작용을 기반으로 또는 메모리 부족과 같은 시스템 조건으로 클래스를 제거할 수 있다. 이런 상황에서는 클래스에 대한 의존성을 최소화하는 것이 좋다.

 

 

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

데이터 모델에서 UI를 도출해야 한다. 데이터 모델은 앱의 데이터를 나타내며, 앱의 UI 요소 및 기타 구성요소로부터 독립되어 있다. 즉, 이들은 UI 및 앱 구성요소 수명 주기와는 관련이 없다. 

데이터 모델 클래스를 기반으로 앱 아키텍처를 구축하면 앱의 테스트 가능성과 견고함이 높아진다.

 

 

단일 소스 저장소 (줄여서 SSOT)

앱에서 새로운 데이터 유형을 정의할 때는 데이터 유형에 단일 소스 저장소를 할당해야 한다. SSOT는 데이터의 소유자이며, SSOT만 데이터를 수정하거나 변경할 수 있다. SSOT는 이를 위해 불변 유형을 사용해 데이터를 노출하며, 다른 유형이 호출할 수 있는 이벤트를 수신하거나 함수를 노출해 데이터를 수정한다.

 

이 패턴에는 여러 가지 이점이 있다.

• 특정 유형 데이터의 모든 변경사항을 한곳으로 일원화한다.
• 다른 유형이 조작할 수 없도록 데이터를 보호한다.
• 데이터 변경사항을 더 쉽게 추적할 수 있도록 한다. 따라서 버그를 발견하기가 쉽다.

오프라인 중심 애플리케이션의 애플리케이션 데이터 정보 소스는 주로 데이터베이스이다. 정보 소스가 ViewModel이거나 UI인 경우도 있다.

 

 

단방향 데이터 흐름 (줄여서 UDF)

Android에서 상태 또는 데이터는 일반적으로 계층 범위의 상위 범위 유형에서 하위 범위 유형으로 흐른다. 이벤트는 보통 하위 범위 유형에서 트리거되어 상응하는 데이터 유형의 SSOT에 도달한다. 예를 들어 애플리케이션 데이터는 보통 데이터 소스에서 UI로 흐른다. 버튼 누르기와 같은 사용자 이벤트는 UI에서 SSOT로 흐르며, SSOT에서는 애플리케이션 데이터가 불변 유형으로서 수정 및 변경된다.

이 패턴은 데이터 일관성을 강화하고, 오류가 발생할 확률을 줄여 주며, 디버그하기 쉽고, SSOT 패턴의 모든 이점을 제공합니다.

---

 

 

 

👍 권장 앱 아키텍처

 

일반적인 앱 아키텍처 다이어그램

 

안드로이드에서 권장하고 있는 앱 아키텍처의 구조는 위의 그림과 같다. 애플리케이션에는 최소한 다음 두 가지 레이어가 포함되어야 한다.

 

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

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

 

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

 

 

 

UI 레이어

앱 아키텍처에서 UI 레이어의 역할

 

UI 레이어의 역할은 화면에 애플리케이션 데이터를 표시하는 것이다. 사용자와 상호작용하고 외부 입력에 변경사항을 반영하도록 UI를 업데이트해야 한다.

 

UI 레이어는 다음 두 가지로 구성된다.

 

 1. 화면에 데이터를 렌더링하는 UI 요소. 이러한 요소는 View 혹은 Jetpack Compose 함수를 사용해 빌드할 수 있다.

 

 2. 데이터를 보유하고 이를 UI에 노출하여 로직을 처리하는 상태 홀도 (예: ViewModel 클래스)

 

 

데이터 레이어

앱 아키텍처에서 데이터 레이어의 역할

 

데이터 영역에는 애플리케이션 데이터 및 비즈니스 로직이 포함된다. 비즈니스 로직은 앱에 가치를 부여하는 요소로, 애플리케이션의 데이터 생성, 저장, 변경 방식을 결정하는 실제 비즈니스 규칙으로 구성된다.

 

앱에서 처리하는 다양한 유형의 데이터 별로 저장소 클래스를 만들어야 한다.

 

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

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

각 데이터 소스 클래스는 파일, 네트워크 소스, 로컬 데이터베이스와 같은 하나의 데이터 소스만 사용해야 한다. 데이터 소스 클래스는 데이터 작업을 위해 앱과 시스템 간의 가교 역할을 한다.

 

 

도메인  레이어

앱 아키텍처에서 도메인 레이어의 역할

 

도메인 레이어는 복잡한 비즈니스 로직이나 여러 ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당한다. 이 레이어는 선택사항임으로 복잡성을 처리하거나 재사용성을 선호하는 등의 필요한 경우에만 사용해야 한다.

 

도메인 레이어는 다음과 같은 이점을 제공한다.

• 코드 중복을 방지
• 도메인 레이어 클래스를 사용하는 클래스의 가독성을 개선
• 앱의 테스트 가능성을 높임
• 책임을 분할하여 대형 클래스를 방지

이러한 클래스를 간단하고 가볍게 유지하려면 각 사용 사례에서는 기능 하나만 담당해야 하고 변경 가능한 데이터를 포함해서는 안 된다. 대신 개발자가 UI 레이어 또는 데이터 레이어의 변경 가능한 데이터를 처리해야 한다.

---

 

 

🚩 일반 권장사항

안드로이드는 필수는 아니지만, 대부분의 경우 장기적으로 더 강력하고 테스트 및 유지관리가 쉬운 코드베이스를 만드는 데 도움이 되는 권장사항을 제공하고 있다.

 

1. 앱 구성요소에 데이터를 저장합니다.

 

2. Android 클래스의 종속 항목을 줄입니다.

 

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

 

4. 각 모듈에서 가능하면 적게 노출합니다.

 

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

 

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

 

7. 유형은 동시 실행 정책을 담당합니다.

 

8. 가능한 한 관련성이 높은 최신 데이터를 보존합니다.

 

---

 

이렇게 해서 안드로이드의 앱 아키텍처 가이드를 살펴보고 학습해보는 시간을 가졌다. 앱에 좋은 아키텍처를 구현하면 다음과 같은 장점이 있다.

 

• 앱의 전반적인 유지관리성, 품질, 견고성이 개선
• 앱을 확장할 수 있습니다. 코드 충돌이 최소화되어 더 많은 인력과 팀이 동일한 코드베이스에 기여할 수 있다.
• 온보딩에 도움이 됩니다. 아키텍처는 프로젝트에 일관성을 부여하므로 새로운 팀원이 빠르게 업무를 시작하고 보다 짧은 시간에 효율을 높일 수 있다.
• 테스트하기가 더 쉽습니다. 좋은 아키텍처는 테스트하기가 더 쉬운 간단한 유형을 사용하도록 지원
• 잘 정의된 프로세스를 사용하여 버그를 체계적으로 조사할 수 있다.

 

좋은 앱을 만들기 위해서는 좋은 아키텍처를 잘 설계하는 것이 매우 중요하다는 것을 느낀다.