[Android] - Clean Architecture

모바일 앱 사용자 환경의 기본 개념

핸드폰을 사용하면서 앱을 잠시 떠나서 다른 앱을 사용하는 상황이 매우 흔하게 발생된다.

예를 들어 인스타와 카카오톡 같은 SNS를 사용하다가 전화가 오거나 알람이 울리면 사용 환경이 중단될 수 있다.

또, 스마트폰의 리소스는 제한되어 있으므로 운영체제가 공간이 필요하다고 판단되면 앱 프로세스를 종료하기도 한다.

이러한 상황이 발생하면 사용자 입장에서 난감하다. 

"아니 인스타 , 카톡 하다가 전화 왔다고 갑자기 앱이 종료된다고?!"

이렇듯 사용자 혹은 운영체제가 앱 구성요소를 제거할 수 있기 때문에 우리는 앱 데이터나 상태를 앱 구성요소에 저장하며 안되며, 앱 구성요소가 서로 종속되면 안 된다. --> 이것이 모바일 앱 사용자 환경의 기본개념이다.

 

클린 아키텍처(Clean Architecture)는 과연 무엇인가?

클린 아키텍처는 개발자들사이에서 유명한 클린 코드를 저술한 인물이 제안한 시스템 아키텍처로, 

기존의 계층형 아키텍처가 가지던 의존성에서 벗어나도록 하는 설계를 제공합니다.

 

위 그림은 시스템을 구성하는 영역을 네 부분으로 나누고 있습니다.

 

💡엔티티(Entities)

• 핵심 업무 규칙을 캡슐화한다.
• 메서드를 가지는 객체, 일련의 데이터 구조와 함수의 집합이다.
• 가장 변하지 않으며, 외부로부터 영향을 받지 않는 영역이다.

💡유즈 케이스(Use Cases)

• 애플리케이션의 특화된 업무 규칙을 포함한다.
• 시스템의 모든 유즈 케이스를 캡슐화하고 구현한다.
• 엔티티로 들어오고 나가는 데이터 흐름을 조정하고 조작한다.

 

💡인터페이스 어뎁터(Interface Adapter)

• 일련의 어뎁터들로 구성한다.
• 외부 인터페이스에서 들어오는 데이터를 유즈 케이스와 엔티티에서 처리하기 편한 방식으로 변환하며, 
  유즈케이스와 엔티티에서 나가는 데이터를 외부 인터페이스에서 처리하기 편한 방식으로 변환한다.
• 컨트롤러, 프레젠터, 게이트웨이 등이 여기에 속한다.

 

💡프레임워크와 드라이버(Frameworks & Drivers)

• 시스템의 핵심 업무와는 관련 없는 세부 사항이다.
• 프레임워크나, 데이터베이스, 웹 서버 등이 여기에 해당한다.

클린아키텍처가 필요한 이유 

내가 개발한 앱이 있는데, 그 앱을 부탁한 회사에서 만약

기존시스템은 유지하고, UI와 DB 등을 바꿔달라고 요구를 받았을 경우를 상상해 보자.

만약 모든 코드를 Fragment, Activity에 작성했다면 바꾸는데 꽤 많은 시간과 노력이 들것입니다.

하지만 클린아키텍처를 도입해서 앱을 개발했다면,

단순하게 인터페이스 어뎁터 영역과 프레임워크와 드라이브 영역만 수정하면 됩니다.

즉 클린아키텍처는 주요 로직은 바꾸지 않으면서, 언제든 DB와 프레임워크에 구애받지 않고 교체할 수 있는 아키텍처라는 뜻입니다.

이러한 이유로 클린 아키텍처로 앱을 개발하는 것이 장기적으로 강력하고, 테스트 및 유지관리가 쉬운 앱을 만들 수 있는 방법입니다.

클린 아키텍처에서 가장 중요시하는 점은 경계를 중요시합니다.

 

클린 아키텍처에서 말하는 경계란?

소프트웨어 아키텍처는 선을 긋는 기술이며, 나는 이러한 선을 경계라고 부른다.
경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다.

 

즉 클린아키텍처는 계층을 크게 나누어서 관심사를 분리하고, 각 분리된 클래스가 한 가지 역할만 할 수 있도록 구현하는 방식이다.

관심사분리

저 같은 경우도 Activity와 Fragment에 모든 동작과 이벤트 처리에 해당하는 코드를 다 작성합니다.

이렇게 코드를 짜는 경우 구성요소 수명 주기와 관련된 많은 문제가 발생합니다.

Activity 또는 Fragment와 같은 UI 기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함해야 합니다.

이러한 클래스를 최대한 가볍게 유지해 주는 것이 수명주기와 관련된 많은 문제를 피할 수 있습니다.

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

 

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

데이터 모델은 앱의 데이터를 나타냅니다. 이들은 앱의 UI 요소 및 기타 구성요소와 독립되어 있습니다.

즉 데이터 모델은 UI 및 앱 구성요소 수명 주기 와는 관련이 전혀 없습니다.

데이터 모델은 지속적 모델을 권장합니다.

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

위와 같은 두 가지 이유로 데이터모델은 지속적 모델을 권장합니다.

 

이상적인 앱 아키텍처

 

위에서 언급된 일반적인 아키텍처 원칙을 고려하여 각 애플리케이션에는 레이어가 두 개 이상 있어야 합니다.

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

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

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

화살표는 클래스 간의 종속 항목을 나타냅니다.

즉 도메인 레이어 -> 데이터 레이어 의 의미는 도메인 레이어는 데이터 레이어 클래스에 의존한다는 뜻입니다.

 

UI 레이어

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

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

 

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

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

 

 

 

데이터 레이어

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

 

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

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

예를 들어 영화 관련 데이터에는 MoviesRepository 클래스,

결제 관련 데이터에는 PaymentsRepository 클래스를 만들 수 있습니다.

Repository의 역할

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

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

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

 

 

도메인 레이어

도메인 레이어는 UI레이어와 데이터 레이어 사이에 있는 선택적 레이어입니다.

 

도메인 레이어는 복잡한 비즈니스 로직, 또는 여러 ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당합니다. 모든 앱에 이러한 요구 사항이 있는 것은 아니므로 이 레이어는 선택사항입니다.

따라서 복잡성을 처리하거나 재사용성을 선호 나는 등 필요한 경우에만 사용해야 합니다.

 

일반적으로 사용 사례 또는 상호사용자라고 하는데, 각 사용 사례에는 하나의 기능을 담당해야 합니다.

예를 들어 여러 ViewModel에서 시간대를 사용하여 화면에 적절한 메시지를 표시하는 경우

앱에는 GetTimeZoneUseCase 클래스가 있다.

 

 

일반 권장 사항

아래 권장사항을 따르면 장기적으로 더 강력하고, 테스트 및 유지관리가 쉬운 코드 베이스를 만들 수 있다고 합니다.

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

 

알게 된 점

• 이러한 클린아키텍처를 무시하고 참 무식하게 코드를 짰네요..
• 디자인패턴과 ViewModel을 공부해야겠다고 느꼈습니다..