앱 아키텍처 - 1 [관심사 분리]

아키텍처 원칙

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

앱의 견고성을 높이며 앱을 쉽게 테스트할 수 있도록 하려면 몇 가지 특정 원칙을 준수하도록 앱 아키텍처를 설계 해야 함

관심사 분리

Activity 또는 Fragement에 모든 코드를 작성하는 실수는 흔히 발생한다.

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

UI 클래스의 경우 최대한 가볍게 유지해야 하는데, 그 이유는 라이프 사이클과 관련된 많은 문제를 피해야하기 때문이다.

 

Activity 및 Fragment 구현은 소유 대상이 아니다

Android OS와 앱 사이를 이어주는 클래스일 뿐

OS는 사용자 상호작용을 기반으로 또는 메모리 부족과 같은 시스템 조건으로 인해 언제든지 제거 될 클래스 이다.

직접 관리 할 수 없는 클래스 이므로 의존성을 최소화 하는 것이 좋다.

단일 소스 저장소

앱에서 새로운 데이터 유형을 정의할 때는 데이터 유형에 단일 소스 저장소(SSOT[Single Source Of Truth])를 할당해야 함
아래는 SSOT의 패턴이다.

• SSOT는 데이터의 소유자 이다
• SSOT만 데이터를 수정 혹은 변경할 수 있다.
• SSOT는 이를 위해 불변 유형을 사용하여 데이터를 노출 한다.
• 다른 유형이 호출할 수 있는 이벤트를 수신하거나 함수를 노출하여 데이터를 수정

이 패턴에는 여러 이점이 있는데

• 특정 유형 데이터의 모든 변경사항을 한곳으로 일원화 함
• 다른 유형이 조작할 수 없도록 데이터를 보호
• 데이터 변경사항을 더 쉽게 추척할 수 있도록 하여, 버그를 발견하기가 쉬워짐

단방향 데이터 흐름

단일 소스 저장소 원칙은 Google 가이드에서 종종 단방향 데이터 흐름(UDF [Unidirectial Data Flow] )패턴과 함께 사용

- UDF에서 상태는 한 방향으로만 흐름

- 데이터 흐름을 수정하는 이벤트는 반대 방향으로 흐름

 

Android 에서 상태 또는 데이터는 일반적으로 계층 범위의 상위 Scope 에서 하위 Scope로 흐름

이벤트는 보통 하위 Scope 에서 트리거 되어 상응하는데, 데이터 타입의 SSOT에 도달 함

예 : 

• 애플리케이션 데이터는 보통 데이터 소스에서 UI 흐름
• 버튼 누르기와 같은 사용자 이벤트는 UI에서 SSOT로 흐름
  • SSOT에서는 애플리케이션 데이터가 불편 유형으로서 수정 및 변경

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