Android CleanArchitecture

DevOks·2021년 8월 22일
0
post-thumbnail

Software Architecture

  • 소프트웨어 요소들과 각 요소의 외부 속성 그리고 이들 사이의 관계를 구성하는 시스템의 구조이다.
  • 소프트웨어 구조(software architecture)는 소프트웨어의 구성요소들 사이에서 유기적 관계를 표현하고 소프트웨어의 설계와 업그레이드를 통제하는 지침과 원칙이다.(위키백과)

Clean Architecture

  • 에자일소프트웨어 개발선언의 일원이기도 한 'Robert C Martin'님이 정의하고 소개한 소프트웨어 아키텍쳐중 하나로서,
    의존성 규칙(Dependency Rule)을 따르며, 소프트웨어 각 계층을 각 관심사에 맞게 분리하고, 쉽게 변경 및 테스트가 가능하도록 설계하는 소프트웨어 구조

Clean Architecture Components

Layers of Android Architecture

  1. Presentation Layer: Fragment, Activity, ViewModels, LiveData 등의 Android FrameWork와 붙어있는 UI영역
  2. Domain Layer: UseCases (행위의 최소 단위), Repository(api, database 통신 행위), Entities(내부적 데이터 객체) 의 영역으로, 한마디로 주요 비지니스 로직(?)의 외부 영역
  3. Data Layer: 정제된 데이터 객체 영역으로 Database, web APIs, Frameworks등의 영역
  4. 의존성 규칙 : 의존성 규칙은 모든 소스코드 의존성은 반드시 외부에서 내부로, 고수준 정책을 향해야만 한다는 규칙. 이를 통해 업무 로직(고수준 정책:주 비즈니스로직)들이 세부 사항들(저수준 정책: DB 또는 Web)의 변경에 영향을 받지 않을 수 있다.

Android CleanArchitecture

  • MVVM (Design Pattern) : MVC,MVI등의 패턴이 존재하지만, 뷰모델과 데이터바인딩에 의한 UI업데이트 이벤트 처리등의 용이함, 구글 안드로이드 레퍼런스의 권장 아키텍쳐등의 이유로 적용

    1. UserInterface(Activity/Fragment) : 유저에게 시각적으로 보이고, 유저와 상호작용하는 뷰 영역
    2. ViewModel : 클래스는 수명 주기를 고려하여 UI 관련 데이터를 저장하고 관리하도록 설계됨
    3. UseCase : 어플리케이션의 주요 로직(?)을 담당하는 영역 - 행동의 최소 단위로 작성
    4. Repository : 유스케이스가 필요로 하는 데이터 반환/저장/매핑 등의 기능을 제공하는 영역
    5. DataSource(Retrofit,Room) : 실제 데이터의 입출력을 처리하는 영역
  • Components

    1. Model : 앱의 실질적인 데이터 도메인영역의 데이터 모델
    2. Entitiy : 데이터 소스에서 사용되는 데이터 모델
    3. LiveData : 안드로이드 수명주기를 상태를 인식하고, 관찰 가능한 데이터 홀더 클래스
    4. Coroutine/Flow : 비동기 프로그래밍 및 데이터 스트림의 업데이트 및 수집을 위한 API
    5. Hilt(DI) : 각 모듈의 의존성 분리 위한, 객체 의존성 주입 라이브러리 Hilt(Dagger)
    6. MapStruct : 객체(DTO~Entity)간의 필드 매핑 코드를 자동으로 생성해주는 매핑 라이브러리
    7. Room : SQLite에 추상화 레이어를 제공하여 SQLite 데이터베이스 액세스/관리하는 API
    8. Retrofit : 서버/네트워크 통신을 위한 HttpClient 라이브러리
  • Example Project

  • Opinion

    • 도메인영역에서의 비즈니스로직은 어떤 코드가 작성되어야 하는가!?
    • UseCase에서 각 액션에 대한 데이터 상태를 직관적으로 알 수있도록, 그리고 다음 API사용에 대한 Flow나, 데이터모델의 정의,저장,변환등의 작업을 작성하는것으로 도메인의 역할(?)을 나름 정리해보긴 하였다.
    • 각 레이어가 나누어지고 테스트가 용이한 클래스들을 작성 할.수.는 있겠지만, 그에 따른 각 단계의 더 많은 코드작성의 증가에 따른 복잡성+코드실수등의 단점등도 존재한다.
    • 이 아키텍쳐로 개발하기 전에도 생각했지만, 프로젝트규모,인원,구조등에 따라 적절한 아키텍쳐를 선택 하는것이 더 좋은 방향일 것이다.

Reference

profile
[Android] Software Engineer

0개의 댓글