[안드로이드] - Android Architecture (안드로이드 아키텍처)

일반 아키텍처 원칙

애플리케이션 데이터와 상태를 저장하는 앱 구성요소를 사용할 수 있다면, 앱을 대신 어떻게 설계를 해야할까?

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

 

앱 아키택처는 앱의 부분과 그 각 부분에 필요한 기능 간의 경계를 정의한다.

 

관심사 분리

Activity 또는 Fragment 에 모든 코드를 작성하는 실수는 흔히 일어난다.

이러한 UI 기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함해야 한다.

이러한 클래스를 최대한 가볍게 유지하여 컴포넌트 생명주기와 관련된 많은 문제를 피하고, 그러한 클래스의 테스트 가능성을 개선할 수 있다.

Activity 또는 Fragment 구현은 소유 대상이 아니며 안드로이드 OS 와 앱 사이의 계약을 나타내도록 이어주는 클래스 일 뿐이다.

또한, 안드로이드 OS는 아래 두 가지 이유로 언제든지 클래스를 제거할 수 있습니다.

• 사용자 상호작용을 기반으로
• 메모리 부족과 같은 시스템 조건으로

 

만족스러운 사용자 경험과 더욱 수월한 앱 환경을 제공하려면 이러한 클래스에 대한 의존성을 최소화하는 것이 좋다.

 

 

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

데이터 모델

• 앱의 데이터를 나타낸다.
• 앱의 UI 요소 및 기타 컴포넌트로부터 독립되어 있다.

 

즉, 데이터모델은 UI 및 앱 컴포넌트 수명 주기(Life cycle)와는 관련이 없다.

그래서 Model은 가급적 지속적인 Model을 사용하는 것이 좋습니다.

 

지속모델 사용하면(도출해야하는 이상적인 이유)

• 안드로이드 OS 에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않습니다.
• 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동한다.

 

앱 아키텍처를 데이터 모델 클래스에 기반하는 경우 앱의 테스트 가능성과 견고성이 더 높아진다.

---

권장 앱 아키텍처

각 애플리케이션에는 최소한 두 가지 레이어가  포함되어야 한다.

• 화면에 애플리케이션 데이터를 표시하는 UI Layer
• 앱의 비즈니스 로직을 포함하고 애플리케이션 데이터를 노출하는 Data Layer

 

UI와 Data 레이어 간의 상호작용을 간소화하고 재사용하기 위한 Domain Layer (optional) 라는 레이어를 추가할 수 있다.

https://developer.android.com/

 

UI Layer

UI 레이어 (또는 프레젠테이션 레이어)의 역할은 화면에 애플리케이션 데이터를 표시하는 것입니다.

사용자 상호작용(ex. 버튼 누르기) 또는 외부 입력(ex. 네트워크 응답) 으로 인해 데이터가 변할 때마다 변경사항을 반영하도록 UI 가 업데이트되어야 합니다.

 

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

• 화면에 데이터를 렌더링하는 UI 요소. 이러한 요소는 뷰 또는 Jetpack Compose 함수를 사용하여 빌드할 수 있다.
• 데이터를 보유하고 이를 UI에 노출하며 로직을 처리하는 State holders (ex. ViewModel 클래스)

* 추가로 UI 레이어 관련 블로그 작성을 할 예정입니다.

 

 

Data Layer

앱의 Data 레이어는 비즈니스 로직이 포함되어 있다.

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

 

Data 레이어는 각각 0개부터 여러 개의 데이터 소스를 포함할 수 있는 저장소로 구성됩니다.

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

예를 들어, 영화 관련 데이터에는 MoviesRepository 클래스를 만들거나, 결제 관련 데이터에는 PaymentRepository 클래스를 만들 수 있다.

 

* 추가로 Data 레이어 관련 블로그 작성을 할 예정입니다.

 

저장소(Repository) 클래스에서 담당하는 작업

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

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

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

 

 

Domain Layer

Domain 레이어는 UI 레이어와 Data 레이어 사이에 있는 선택적 레이어다.

 

Domain 레이어의 역할

• 복잡한 비즈니스 로직  또는 여러 ViewModel 에서 재사용되는 간단한 비즈니스 로직의 캡슐화

 

해당 레이어는 선택사항입니다. 따라서 복잡성을 처리하거나, 재사용성을 선호하는 등 필요한 경우에만 사용한다.

그리고 Domain 레이어의 클래스는 일반적으로 사용 사례 또는 상호작용자라고 한다.

각 사용 사례에서 하나의 기능을 담당해야 한다.

예를 들어, 여러 ViewModel 에서 시간대를 사용하여 화면에 적절한 메시지를 표시하는 경우, 앱에는 GetTimeZoneUseCase 클래스를 별도로 만들 수 있다.

 

* 추가로 Domain 레이어 관련 블로그 작성을 할 예정입니다.

 

---

구성 요소 간 종속 관리

앱의 클래스는 올바른 작동을 위해 다른 클래스에 종속된다.

특정 클래스의 종속 항목을 수집하는데, 두 가지 디자인 패턴 중 하나를 사용할 수 있다.

• 종속 항목 주입(DI) : 종속 항목 주입을 사용하면 클래스가 자신의 종속 항목을 구성할 필요 없이 종속 항목을 정의할 수 있다. 런타임 시 다른 클래스가 이 종속 항목을 제공해야 한다.
• 서비스 로케이터 : 클래스가 자신의 종속 항목을 구성하는 대신, 종속 항목을 가져올 수 있는 리제스트리를 제공한다.

위 패턴들은 코드를 중복하거나 복잡성을 추가하지 않아도 종속 항목을 관리하기 위한 명확한 패턴을 제공하므로 코드를 확장할 수 있다.

또한, 이러한 패턴을 사용하면 테스트와 프로덕션 구현 간에 신속하게 전활 할 수 있다.

---

일반 권장사항

다음 권장사항은 필수는 아니지만, 대부분의 경우 장기적으로 더 강력하고 테스트 및 유지관리가 쉬운 데이터베이스를 만드는 데 도움이 될것이다.

 

• 앱 구성 요소에 데이터를 저장하라
• Android 클래스의 종속 항목을 줄여라
• 앱의 다양한 모듈 간 책임이 잘 정의된 경계를 만들라
• 각 모듈에서 가능하면 적게 노출하라
• 다른 앱과 차별되도록 앱의 고유한 핵심에 초점을 맞춘다.
• 앱의 각 부분을 독립적으로 테스트하는 방법을 고려하라
• 가능한 한 관련성이 높은 최신 데이터를 보존하라

 

 

 

 

참고

https://developer.android.com/topic/architecture?hl=ko 

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