[Android] 안드로이드 clean architecture

fanthasium·2023년 6월 21일

아키텍처의 필요성

Android 앱은 아래의 기본 구성요소 를 manifest에서 재정의 해 사용한다

Activity
Fragments
Services
Contet providers
Broadcast receivers

이러한 , 기본 요소로 통합된 앱이 짧은 시간 내에 사용자 중심의 다양한 워크플로를 맞출 수 있게 하며, 휴대기기의 제한된 리소스를 효율적으로 사용하려면

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

**그렇다면 데이터와 상태를 어떻게 앱 구성요소를 사용하지않고 저장할 수 있을까?**

바로,

그리고 이러한 정의를 충족하려면 특정 원칙을 준수해야한다

UI 기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함한다
- Activity와 Fragment는 각각의 수명주기를 갖고 있으며 Android OS와 앱 사이의 다리 역할을 하고있는 것

-클래스 의존성 최소화를 위함

-데이터 모델 클래스에 기반하여 UI를 도출하는 것

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

핵심은 권장 패턴은 MVVM 패턴이다.
MVP , MVC 패턴이 존재하긴 하나 Activity의 과부화, 리소스 양의 증가 와 재사용성 으로 인해 권장하는 듯 하다

UI Layer

UI Layer
- 데이터가 변할 때마다 변경사항을 반영하도록 UI가 업데이트되어야 한다.
  
  View or Jetpack Compose : 화면에 데이터를 렌더링
  
  ViewModel 클래스 : 보유한 데이터를 UI에 노출

또한 아래 이미지는 view 와 compose의 데이터 흐름을 보여주는데 UDF ( 단방향
상태임을 알수 있다

Data Layer
- 앱의 데이터 레이어에는 비즈니스 로직이 포함되어 있다
  -Business Logic?
  앱에 가치를 부여하는 요소로, 앱의 데이터 생성, 저장, 변경 방식을 결정하는 규칙으로 구성됨.
  
  때문에
  ” 정보는 일관되고 최신화 돼 있는 것이 좋은 사용자 경험을 만들어 주기에 ”
  아래처럼 앱에서 처리하는 다양한 유형의 데이터마다 저장소 클래스를 만들어야 한다

Domain Layer
- 도메인 레이어는 UI 레이어와 데이터 레이어 사이에 있는 선택적 레이어(Optional)
- 여러 ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당한다
  
  즉 권고사항 이기때문에 ViewModel에서 사용하는 비즈니스 로직을 따로 뺴 UseCase로 넣는 것이며 이러한 dataLogic을 재사용할 수 있다
  
  why? DomainLayer
  
  ViewModel은 View와 1:n 의 관계이기에 ViewModel에서 직접적으로 Repository에 관여한다면 유지보수가 힘들고 의존성이 높아짐
  따라서 ,
  RepositoryInterface,UseCase를 사용해 state 변화만 감지해주는 것이 좋음
  
  모든 앱에 이러한 요구사항이 있는 것은 아니므로 이 레이어는 선택사항

정리하자면

이런식의 flow가 나온다

presentation layer : data를 화면에 표시하고 user 상호작용을 다룸. UI, Presenter, ViewModel등.
domain layer : 비지니스 프로세스와 관련된 가장 핵심 계층. 어떤 다른 계층에도 독립적임. Entities, Use Case, Repository Interface등.
data layer : 어플리케이션의 데이터 관리(네트워크에서 데이터 검색, 데이터 캐시 관리 등). Repository Implementation, Local & Remote Data source등.

디그다 디그다 (끙챠끙챠)