[안드로이드/Android] 클린아키텍처 Clean Architecture

 

클린 아키텍처 Clean Architecture

개발자 로버트 C. 마틴(Robert C. Martin)가 2012년 엔터프라이즈 아키텍처에서 논의된 내용을 토대로 집약시킨 개념.
소프트웨어의 관심사를 계층별로 분리하는 소프트웨어 디자인 철학이다.
주요 원칙은 코드 종속성이 외부로부터 내부로 의존한다는 것이다.(외부->내부 로 향하여 의존한다.)
내부 계층의 코드는 외부 계층의 기능을 알 수 없다.

UI와 Database를 분리하여, 외부적인 설정에는 독립적이며 프레임워크에 의존적이지 않은 공통적인 코드를 짤 수 있도록 한다.
클린 아키텍처는 2가지 관점에서 볼 수 있다.
1. 아키텍처 설계 철학 - SOLID 원칙을 기반으로함 
   : 단일 책임 원칙(Single Responsibility Principle)을 시작으로 한 다섯 가지 원칙 등을 중심으로 
     이제까지 SW 설계에서 중요하게 거론되어온 다양한 원칙들을 일목요연하게 정리하고 있다.
     코드의 가독성을 높이고 확장이 쉬운 구조를 만드는 지침이다.
     ⓵ 단일 책임 원칙 (Single Responsibility Principle)
     ⓶ 개방 폐쇄 원칙 (Open Closed Principle)
     ⓷ 리스코프 치환 원칙 (Liskov Substitution Principle)
     ⓸ 인터페이스 분리 원칙 (Interface Segregation Principle)
     ⓹ 의존 역전 원칙 (Dependency Inversion Principle)

[SOLID 원칙] https://www.charlezz.com/?p=1452

2. 아키텍처 Blue Print(청사진) 
   : Hexagonal Architecture, Onion Architecture 등 당시 널리 알려진 아키텍처들의 공통된 성과물을 정리한 것. 
     모바일부터 백엔드까지 모든 소프트웨어에 일반적으로 필요한 내용을 담고 있으며, 
     각 계층을 어떻게 나누고 어떤 요소로 구성할 것인가에 대한 원칙.
     가운데로 갈 수록 높은 수준, 바깥으로 갈 수록 낮은 수준의 컴포넌트로, 
     이에 대한 효율적인 분리로 효과적인 설계가 가능하다.

참고  https://blog.insightbook.co.kr/2019/08/08/%ED%81%B4%EB%A6%B0-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98/

 

🚨 Clean Architecture 구조 및 주요 특징

Clean ArchitectureBlue Print

 

경계선(Boundaries) : 계층 구조의 개념이 널리 적용됨.
유스케이스(Use Case) : 도메인 계층의 분리로 소스코드 변경 안정성(stability)이 높아짐.
험블 객체(Humble Object) : 프리젠테이션 계층의 테스트 가능성, 가독성, 유지보수성을 향상.
의존성 역전(DIP) : modular한 프로젝트 구조의 확산.
-> 3가지 계층을 분리하여 관심사를 분리.

 

가운데 원은 가장 추상적인 영역. 
비즈니스 로직을 포함하고 사용 중인 플랫폼이나 프레임워크에 의존해서는 안된다.

외부 원은 네트워크 및 데이터베이스의 접근처럼 플랫폼에 특정한 구체적인 구현 세부사항이 포함된다.

바깥쪽에서 안쪽으로 참조하며, 안쪽 계층으로 진입할수록 추상화와 캡슐화 수준이 높아진다.

클린 아키텍처를 사용했을 때의 장점 : 계층을 분리하고 계층 간의 의존성을 단방향으로 만들기 때문에 코드의 재사용성이 용이해지고, 유닛 테스트가 쉬워진다.

 

Entities

엔티티(Entities) 계층은 전사적 비즈니스 규칙을 캡슐화 한다. 데이터의 구조나 메서드를 포함하고 있는 객체.
하나의 애플리케이션을 위한 엔티티라면 애플리케이션의 비즈니스 로직을 담고, 가장 일반적이고 상위 수준의 규칙들을 캡슐화한다.
화면 등 외부에서 변경된 것이 있다면 이 계층은 영향을 받지 않아야 한다.
데이터 클래스들이 이 계층에 속하고, 안드로이드 애플리케이션과 관련된 코드는 포함해서는 안된다.

Use Cases

유즈케이스(Use Cases) 계층에서는 애플리케이션과 관련된 비즈니스 규칙을 포함하고
시스템의 모든 유즈케이스 구현체들을 캡슐화한다. 
엔티티로부터 데이터 흐름들을 관리하고, 엔티티에게 비즈니스 규칙의 사용을 전달한다.
이 계층은 엔티티 계층에 영향을 미치지 않으며, 외부 계층이나 UI 또는 프레임워크로부터의 영향을 받지 않는다.
안드로이드에서는 Model, Repository, Executor 등과 관련된 내용이 이 계층에 속한다.
   - Model : 데이터베이스의 질의나 네트워크 요청 등의 비즈니스 로직 수행
   - Repository : 내부 DB 접근/저장, 서버에 데이터 요청 등의 역할. 일반적으로 인터페이스로 구성.
   - Executor : Repository 나 Model 에 관련된 작업들이 백그라운드에서 작업을 수행할 수 있도록 작업 스레드를 관리하고 제공.

Interface

유즈케이스나 엔티티로부터 얻은 데이터를 가공하여 비즈니스 로직과 UI 프레임워크를 연결하는 계층.
아키텍처 디자인패턴에서 Presenter, View, ViewModel, Controller 등과 같은 관심사가 이 계층에 속한다.
비즈니스 로직을 수행하여 DB 나 서버로 부터 전달받은 데이터를 UI 에 표현할 때 이 계층에서 데이터를 가공하여 전달한다.
반대로, UI 로부터 얻은 데이터를 DB 나 서버로 전송할 때 이 계층에서 데이터를 가공하여 전달한다.
비즈니스 로직(DB, 서버) -> UI
비즈니스 로직(DB, 서버) <- UI

Frameworks & Drivers

가장 바깥쪽 계층. 일반적으로 안드로이드에서 UI와 관련된 액티비티, 프레그먼트, 인텐트 전달, 콘텐트 프로바이더 등이 포함된다.
그리고 데이터에 접근하고 Retrofit 과 같은 네트워크와 관련된 프레임워크 코드가 이 계층에 속한다.
애플리케이션 개발자가 프레임워크 코드를 수정할 일은 많지 않다.

 

🚨 안드로이드 CleanArchitecture 3가지 계층

안드로이드에서 클린 아키텍처의 구조는 총 3가지 계층(Presentation Layer, Domain Layer, Data Layer) 으로 되어 있다.

계층을 분리하는 이유는 각 계층을 분리하여 관심사를 분리시키기 위해서이다. 이렇게 분리된 계층으로 이루어진 아키텍처가 동작하기 위해서는 의존성 규칙을 지켜야 한다.
즉, 분리된 각각의 클래스는 한가지 역할만 하고, 서로 의존을 어떻게 할지 규칙을 정하고, 그 규칙을 지켜야 한다.

[의존성] 예를 들어 서비스로 사용할 수 있는 객체. 클라이언트가 어떤 서비스를 사용할 것인지 지정하는 대신, 클라이언트에게 무슨 서비스를 사용할 것인지를 말해주는 것

[주입] 은 의존성(서비스)을 사용하려는 객체(클라이언트)로 전달하는 것

모든 소스코드 의존성은 외부(저수준) -> 내부(고수준) 로 향해야 한다.
원 안쪽으로 갈수록 의존성이 낮아진다. (외부로부터 내부로 의존한다. 내부 계층의 코드는 외부 계층의 기능을 알 수 없다.)

예를 들어, ViewModel(비즈니스 로직을 담당) 이 DB 또는 Web 등(구체적인 세부 사항 담당) 에 의존하지 않아야 한다.
이를 통해 비즈니스 로직(고수준) 은 세부사항들(저수준) 의 변경사항에 영향을 받지 않도록 할 수 있다.
예를 들어, 다른 Android App 개발자가 UI 수정을 위해 변경되어야 하는 부분은 Presentation Layer쪽을 파악하고 수정하는 것이다.
반대로 Network 통신부분의 쿼리가 변경되었다면 Data Layer쪽을 파악하고 수정한다.

모바일(안드로이드) 클린 아키텍처

Presentation Layer

화면 조작 또는 사용자의 입력을 처리하기 위한 관심사를 모아 놓은 레이어.
UI(Activity, Fragment), Presenter 및 ViewModel 을 포함. 
화면과 입력에 대한 처리 등 UI 와 직접적으로 관련된 부분을 담당.
Domain, Data 레이어를 포함하고 있다는 특징이 있다.

• View - Activity, Fragment
• Presenter - Controller, Presenter, ViewModel

 

Domain Layer

애플리케이션의 비즈니스 로직을 포함.
비즈니스 로직에서 필요한 Model 과 각 개별 기능 또는 비즈니스 논리 단위인 UseCase 를 포함.
Presentation, Data 레이어와 어떤 의존성도 맺지 않고 독립적이다. 

• UseCase
• Translater(Entity => Model)

 

Data Layer

Repositoy 구현체인 Cache, Room DB, Dao, Model, 서버API(Retrofit2) 등을 포함.
로컬 또는 서버 API와 통신하여 데이터를 CRUD 하는 역할.
Mapper 클래스도 포함.
DB 로 부터 받아온 데이터모델과 UI에 맞는 데이터모델 간의 변환을 해주는 역할.
Domain 레이어를 포함하고 있다는 특징이 있다.

• Repository - Domain과 Data Store, Remote Layer를 연결하기위함
• Entity - 최소단위의 비즈니스 개체

 

https://developer.android.com/jetpack/guide?hl=ko 

앱 아키텍처 가이드  |  Android 개발자  |  Android Developers