앱 아키텍처의 이해

최성훈·2022년 10월 16일
0

앱 아키텍처 가이드

모든 내용은 android 공식 docs 기반
https://developer.android.com/topic/architecture#recommended-app-arch

모바일 앱 사용자 환경

개발자는 앱 매니패스트에서 구성요소의 대부분을 선언하며 Android OS는 이 파일을 사용하여 기기의 전반적인 사용자 경험에 앱을 통합. 많은 구성요소, 짧은 시간 내 여러 앱과 상호작용 하려면 워크플로 및 잡업에 맞게 조정될 수 있어야 한다.

구성요소는 개별적, 비순차적으로 실행 가능하며 운영체제나 사용자가 언제든지 구성요소를 제거할 수 있음. 이러한 이벤트는 직접 제어가 불가능 따라서 앱 구성요소에 애플리케이션 데이터나 상태를 저장해서는 안되며 앱 구성요소가 서로 종속되면 안됨.

일반 아키텍처 원칙

  1. 관심사 분리 - 가장 중요한 원칙

    UI 기반 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함해햐 한다. 최대한 가볍게 위지하여 구성요소 수명 주기와 관련된 문제를 피할 수 있다. 즉 의존성을 최소화 해야한다.

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

    데이터 모델에서 UI를 도출해야 한다. 지속적 모델을 권장하며 데이터 모델은 앱의 데이터를 나타낸다. 앱의 UI 요소 및 기타 구성요소로부터 독립되어 있다. 즉, 이들은 UI 및 앱 구성요소 수명 주기와는 관련이 없다. 하지만 OS가 메모리에서 앱의 프로세스를 삭제하기로 결정하면 데이터 모델도 삭제된다.

→ 지속적인 모델을 사용해야 하는 이유

  • Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않는다.
  • 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동한다.
  • 앱의 테스트 가능성과 견고성이 더 높아진다.
  1. 단일 소스 저장소

    새로운 데이터 유형을 정의할 때 단일 소스 저장소(SSOT) 를 할당해야함. SSOT는 데이터의 소유자, SSOT만 데이터를 수정하거나 변경할 수 있다.

    SSOT는 이를 위해 불변 유형을 사용, 데이터를 노출하며 다른 유형이 호출할 수 있는 이벤트를 수신하거나 함수를 노출하여 데이터를 수정한다.

→ 이 패턴의 이점

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

    단일 소스 저장소 원칙은 종종 단방향 데이터 흐름(UDF) 패턴과 함께 사용된다 UDF에서 상태는 한 방향으로만 흐른다. 데이터 흐름을 수정하는 이벤트는 반대 방향으로 흐른다.

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

    → 데이터 일관성 강화 및 SSOT 패턴의 이점 제공

권장 앱 아키텍처

일반적인 아케텍처 원칙에 따라 각 어플리케이션은 다음 두 레이어를 포함해야 한다.

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

UI와 데이터 레이어 간 독립을 위해 도메인 레이어를 추가할 수 있음.

UI 레이어

https://developer.android.com/jetpack/guide/ui-layer

화면에 애플리케이션 데이터를 표시하는 것. 사용자 상호작용 또는 외부 입력으로 인해 데이터가 변할 때마다 변경사항을 반영하도록 UI가 업데이트되어야 한다. 즉 UI는 데이터 레이어에서 가져온 애플리케이션 상태를 시각적으로 나타낸다. → UI가 표시할 수 있는 형식으 변환한 후 표기한는 파이프라인

  • 화면에 데이터를 렌더링하는 UI 요소, 이러한 요소는 뷰 또는 Jetpack Compose 함수를 사용하여 빌드할 수 있다.
  • 데이터를 보유하고 이를 UI에 노출하며 로직을 처리하는 상태 홀더(예: ViewModel)

데이터 레이어

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

데이터 레이어는 각각 0개부터 여러 개의 데이터 소스를 포함할 수 있는 저장소로 구성된다. 유형별로 저장소 클래스를 만들어야 한다.

예를들면 영화 → MoviesRepository , 결제 관련 데이터 → PayRepository

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

각 소스 클래스는 파일, 네트워크 소스, 로컬 데이터베이스와 같은 하나의 데이터 소스만 사용해야함. 다른 레이어는 데이터 소스에 직접 접근해선 안되고 데이터 영역의 진입점은 항상 저장소 클래스여야 한다.

이 레이어에서 노출된 데이터는 변경 불가능해야 한다.

데이터 소스 클래스는 DI로 사용해야 한다.

https://developer.android.com/jetpack/guide/data-layer

도메인 레이어

선택적 레이어로 비즈니스 로직, ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당.

복잡성을 처리하거나 재사용성 선호 시 선택

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

간단하고 가볍게 유지하려면 기능 하나만 담당, 변경 가능한 데이터를 포함해서는 안된다.

아키텍처의 이점

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

0개의 댓글