[Android] Clean Architecture란

Clean Architecture 란?🤷🏻‍♂️

Uncle Bob인 로버트 C. 마틴의 Clean Architecture에서 시작. 소스 코드만 보고 소프트웨어가 수행하는 작업이 무엇인지 식별할 수 있어야 하는 소프트웨어 개발 방법론입니다. 프로그램의 목표를 달성하는 데 필요한 프로그래밍 언어, 하드웨어 및 소프트웨어 라이브러리는 구식이어야 합니다.

 

Clean Architecture 장점

• 코드는 표준 MVVM 보다 테스트하기 쉽다.
• 완벽하게 선별된 분리
• 사용자 친화적인 패키지 구조
• 프로젝트를 계속 실행하기 쉽다.
• 새로운 기능을 추가하기 용이하다.

Clean Architecture 단점

• 러닝 커브가 가파르다.
• 많은 추가 클래스가 포함되므로 정교함이 낮은 소프트웨어에는 적합하지 않다.

Clean Architecture 특징🔥

• 새로운 기능이 추가되거나 내부 로직이 변경되어야 할 때 유연하게 대처할 수 있도록 구조화할 수 있습니다.
• 프레임워크와 독립적입니다. 아키텍처는 기능이 풍부한 소프트웨어의 일부 라이브러리의 존재에 의존하지 않습니다. 이렇게 하면 시스템을 제한된 제약조건에 밀어 넣지 않고 이러한 프레임 워크를 도구로 사용할 수 있습니다.
• 비즈니스 로직은 UI, 데이터베이스, 웹 서버 또는 기타 외부 요소 없이 테스트할 수 있습니다.
• UI와 무관합니다. UI는 시스템의 나머지 부분을 변경하지 않고도 쉽게 변경할 수 있습니다.
• 데이터베이스와 독립적입니다. Oracle 또는 SQL Server를 Mongo, BigTable, CouchDB 또는 다른 용도로 바꿀 수 있습니다. 비즈니스 로직은 데이터베이스에 바인딩되지 않습니다.
• 외부 기관과 무관합니다. 비즈니스 로직은 단순히 외부 세계에 대해 전혀 알지 못합니다.

비즈니스 로직이란🚀

하나의 프로젝트나 프로그램 중 업무와 관련된 처리를 하는 일부분을 뜻하는데 프로젝트를 하면서 데이터베이스에서 어떠한 자료를 가져와 웹에서 출력을 할 때 데이터베이스 연결, 통신 , 자료, 가공, 페이지 구성 등 여러 작업을 하지만  그중에서 사용자가 원하는 자료의 가공 부분을 의미합니다. 즉 어떻게 데이터가 생성, 저장되고 수정되는지를 정의한 것입니다.

의존성 규칙🔗

클린 아키텍처

 

대개 바깥쪽으로 향할수록 고수준의 소프트웨어가 되는 경우가 많습니다. 이때 바깥쪽 계층은 메커니즘이고 안쪽의 계층은 정책입니다. 위의 아키텍처를 가능하게 하는 중요 규칙은 바로 의존성 규칙입니다.

• 규칙에 의해서 소스 코드는 안쪽을 향해서만 의존할 수 있고, 안쪽의 계층은 바깥쪽 계층에서 선언된 어떤 요소를 안쪽 계층에서는 참조하거나 영향을 줘서는 절대 안 됩니다.
• 마찬가지로 바깥쪽 계층에서 사용하고 있는 요소를 안쪽의 계층에서 사용해선 안됩니다.
• 결론적으로, 각각 클래스는 한 가지 역할만 수행하게 만들고, 서로의 의존관계를 어떻게 할지 규칙을 정해주어야 합니다.

메커니즘 : 어떤 일을 어떻게 할 것인가를 결정 (How)

정책 : 무엇을 할 것인가를 결정(What)

안드로이드에서 검색 기능을 구현하고자 할 때, 사용자가 검색 버튼을 누르면 사용자는 한 번에 검색 결과가 나오는 것처럼 보이지만, 실제로는 내부 비즈니스 로직에 의해 검색 결과가 추출됩니다. 클린 아키텍처를 따라가면 바깥쪽 계층인 View에서는 단순하게 보여주기만 하지만, 안쪽에서는 어떻게 검색 값을 받아 처리할지 결정해야 합니다.

반응형

이러한 의존성 규칙을 따라 구성하는 4가지 계층

• Entity
  • 비즈니스 로직을 캡슐화하는 계층
  • 메서드를 갖는 객체일 수 있으나 데이터 구조, 함수의 집합일 수도 있습니다.
  • 가장 일반적이면서 고수준의 규칙을 캡슐화
  • 바깥쪽의 어떤 것이 변경되더라도 절대 바뀌지 않습니다.
  • 애플리케이션이 어떤 동작하더라도 Entity 계층에는 영향을 주어선 안됩니다.
• Usecase
  • 애플리케이션의 고유 비즈니스 로직을 포함하며, 시스템의 모든 UseCase를 캡슐화하고 구현
  • Entity의 데이터 흐름을 제어
  • UseCase의 변경이 일어나더라도 Entity에는 영향을 주지 않아야 합니다.
  • 개발자에게 중요한 것은 UseCase가 정확하게 동작하는 것
  • UseCase의 동작 결과를 확인하는 작업을 진행할 때 UI를 필요로 하는 경우는 없어야 합니다.
  • Interactors라고도 칭해집니다.
• Interface Adapter
  • View 등 외부 기능 혹은 사용 중인 프레임워크에 용이한 형식으로 데이터를 변환한다.
  • 안드로이드 MVVM 패턴에서는 ViewModel 영역이다.
  • Model -> UseCase -> ViewModel로 돌아가는 데이터 구조일 가능성이 높다.
  • 결론적으로 순수한 비즈니스 로직만을 담당하는 역할을 한다.
• Frameworks & Drivers(Web, DB)
  • 데이터베이스, 웹 프레임워크 등이 위치
  • 웹이든 데이터베이스든 상세한 정보는 모든 이 계층에 둡니다.
  • 안쪽의 계층과 통신할 연결 코드 외에는 별다른 코드를 작성하지 않습니다.
  • UI에는 내가 하고자 하는 것들 UseCase를 구현하는 것이 아니라, 오로지 세부사항입니다.
  • UI는 단지 내가 무언가를 사용자들에게 보여줄 때나 필요한 것입니다.

Clean Architecture in Android📱

• 2012년 Clean Architecture에 관한 글이 공개된 이후, 해당 아키텍처를 모바일 설계에 도입할 수 있을까에 대한 많은 논의가 있었습니다.
• 결과적으로 4개의 계층을 재구성하여 3개의 계층으로 분리하는 것으로 일반화되었습니다. 
• 각 계층이 자체 데이터 모델을 사용하므로 계층 간 독립성을 확보할 수 있다는 것이 중요합니다.
  • 이때 계층 간 데이터 변환을 수행하기 위해 Mapper가 필요해집니다.

Domain Layer

• 비즈니스 로직을 포함하고 있으며, 이에 필요한 Entity와 Usecase, Repository를 포함
• Domain 계층은 Presentation 계층, Data 계층과 어떠한 의존성을 맺지 않아야 합니다.
• 순수 코틀린 혹은 자바 코드로 구성되어 있어 다른 프레임 워크에서도 유연하게 사용이 가능

UseCase

• 각 기능 혹은 비즈니스 로직 단위로 구성
• 이름만 보고 어떤 기능을 수행하는지 짐작할 수 있어야 합니다.
• Presentation 계층의 UI에서 어떤 이벤트 혹은 동작에 의해 호출되는 방향으로 설계
• Data계층에서 실제 데이터를 어떻게 가져올지 정의는 하지 않고, 해당 메서드를 호출하는 방식으로 데이터를 저장

Translator

• Data 계층의 Entity를 Domain 계층의 Model로 변환

Repository

• Domain 계층에서는 인터페이스로 정의하고, 실제 구현은 Data 계층에서 진행

Model

• 애플리케이션의 실질적 데이터가 여기에 구현
• 안드로이드와 의존성을 가지고 있어선 안되고, 다른 프로젝트에서도 동일하게 사용할 수 있는 클래스를 작성해야 합니다.

---

Data Layer

• Data 계층은 Domain 계층의 의존성을 갖습니다.

Repository

• UseCase가 필요로 하는 데이터 저장, 수정 등의 기능을 제공
• 위의 Domain계층에서 설계한 Repository를 실제고 구현

DataSource

• 실제 데이터의 입출력을 진행
• Room을 사용한다고 하면 Dao를 이 부분에서 접근하고 결과를 출력

Entity

• Domain 계층의 Model과는 다르게, REST API의 요청/응답을 위한 JOSN, 로컬 DB에 저장하기 위한 테이블에 저장하기 위한 데이터를 저장.

---

Presentation Layer

• 내부적으로 프레임워크 의존성을 처리하기 위해 MVP 혹은 MVVM 패턴을 사용
• Activity, Fragment, Presenter, ViewModel을 포함

View

• UI 구현과 사용자 입력만을 담당
• 화면에 그려지는 것이 어떤 의미가 있는지 전혀 알지 못해야 합니다.
• 데이터를 지니고 있더라도 화면과 관련된 데이터만 지니고 있어야 합니다.

Presenter or ViewModel

• View와 달리 플랫폼에 직접적으로 의존하지 않으므로 단위 테스트가 가능
• 또한 화면에 그려지는 것이 어떤 의미를 가지고 있는지 알고 있습니다.
• 사용자 입력이 왔을 때 어떤 반응을 해야 하는지에 대한 판단도 이곳에서 진행
• Domain 계층의 UseCase를 주입받아 데이터를 가져옵니다.
• 당연히, Data 계층에 의존성이 없기 때문에 데이터를 가져오는 과정에 접근할 수 없습니다.

 

출처
https://github.com/hoyahozz/Clean-Architecture-Study