Android Clean Architecture란?

Clean Architecture 사용 이유?

1. Clean Architecture는 프레임 워크에 독립적입니다.
   • Clean Architecture는 일부 기능이 포함된 라이브러리 (곧 프레임워크)에 의존하지 않습니다.
   • 이를 통해 프레임워크의 제약에 시스템을 맞추는 것이 아니라, 시스템의 도구로써 프레임워크를 활용할 수 있게 합니다.
2. Clean Architecture는 테스트를 용이하게 해줍니다.
   • The business rules(Entity)를 테스트하는데에 외부 요소를 필요로 하지 않습니다.
3. Clean Architecture는 UI에 독립적입니다.
   • 다른 시스템 변경 없이, UI를 쉽게 변경할 수 있습니다. (UI 변경의 용이성을 줍니다.)
     • 예들 들면, 웹 UI에서 Console UI로 변경한다 할때, The business rules(Entity)를 변경없이 그대로 사용할 수 있습니다.
4. Clean Architecture는 DB와 독립적입니다.
   • The business rules(Entity)이 DB에 바인딩 되지 않으므로, DB의 종류를 쉽게 변경할 수 있습니다.
     • 예를 들면, Oracle에서 SQL Server, for Mongo, BigTable, CouchDB 등등으로 쉽게 변경 가능합니다.
5. Clean Architecture는 외부와 독립적입니다.
   • The business rules(Entity)는 외부에 대해 알필요가 없고, 전혀 알지 못합니다.
     • 이 덕분에 1-4의 이점을 가져올 수 있는 것입니다.

 

 

위 그림에서 의존성 법칙은 Entites로 향하는 화살표를 의미합니다. 즉, 항상 원의 안쪽 방향으로만 의존성이 존재해야하고, 바깥쪽 방향으로의 의존성은 존재하지 않아야한다는 의미로 해석할 수 있습니다.

 

• 그림에 따르면, 바깥 쪽의 요소 A는 안쪽의 요소 B를 필요로 합니다.
• 그렇다면 과연, 안쪽의 요소 B는 바깥 쪽의 요소 A를 절대 필요로 하지 않을까요?
  -그렇지 않습니다. 다만 이 B가 의존 관계를 회피하여 A를 사용할 뿐입니다.

• 의존의 방향은 변경의 유연성과도 관련이 있습니다.
  Clean Architecture에선, 의존의 방향이 안쪽으로만 향하기 때문에, 바깥쪽에 있을수록 변하기 쉬운, 안쪽에 있을수록 변하기 어려운 요소라 이해할 수 있습니다.

 

Clean Architecture의 Layer

 

Presentation Layer

위 그림의 Presenter를 Presenters뿐만 아니라, ViewModels도 포괄하기 위한 말로, Controllers라 부르겠습니다.

• UI (Activities & Fragments), Controllers (Presenters/ViewModels) 를 포함합니다.
• Controllers (Presenters/ViewModels)은 1개 이상의 Use cases를 실행합니다.
• UI은 UI 각각의 Controllers (Presenters/ViewModels)에 의해 조정됩니다.
• Presentation Layer는 Domain Layer을 대상으로 의존성을 가집니다.

Presentation Layer - - - > Domain Layer

 

Domain Layer

• Entities, Use cases, Repository Interfaces를 포함합니다.
• Use cases는 data와 1개 이상의 Repository Interfaces를 결합합니다.
• Domain Layer는 가장 안쪽의 레이어입니다.
  Domain Layer는 다른 레이어를 대상으로 의존성을 가지지 않습니다.
  다른 레이어가 Domain Layer를 대상으로 의존성을 가질 뿐입니다.

Domain Layer는 Repository를 추상화시켜 사용하고 있기 때문에, 위와 같은 의존이 생겨나지 않게 되는 것입니다.
즉, Domain Layer는 Data Layer에서 구현될 Repository Interfaces를 사용하면서, 의존을 회피하게 됩니다.

 

Domain Layer의 특징

• 잘 바뀌면 안됩니다.
  • 이 Domain Layer에 소프트웨어의 중심이 되는 The business rules(Entity)가 포함됩니다.
• Domain Layer는 다른 레이어를 대상으로 의존성을 가지지 않습니다.
  • 즉, Domain Layer는 프레임 워크(Android Platform)에 의존성을 가지지 않고, 오직 언어 단(Kotlin Module)에 대해서만 의존성을 갖습니다.
    • 따라서, 프레임 워크간의 Domain Layer 재사용도 가능합니다.

 

Data (DataSource) Layer

• Repository Implementations, 1개 이상의 Data Sources를 포함합니다.
• Repository는 다른 Data Source들을 결합/조정합니다.
  -Repository 여러 Data Source들을 결합하는 경우로, Local Data Source과 Remote Data Source의 결합에 대해 이야기할 수 있습니다.
• Data Layer는 Domain Layer을 대상으로 의존성을 가집니다.

Data Layer - - - > Domain Layer

 

 

Use Case

: 어플리케이션이 수행하고자 하는 핵심적인 기능
클린아키텍쳐의 핵심은 코어 비즈니스 로직을 바뀔 수 있는 모든것으로부터 분리하자라는 생각

 

UseCase를 사용하는 이유

• 사용자가 수행하려는 기능 명확하게 정의
• UseCase로 시스템이 수행해야하는 행위를 정의 -> 프로젝트의 구성요소를 UseCase내에서 사용하여 목적을 달성 -> 각 Layer의 격리 도움

 

장점

• UseCase를 사용함으로써 ViewModel에 로직이 집중되는 것을 피할 수 있음
• 다른 ViewModel에서 같은 로직을 사용할 경우 재활용가능
• 각 기능을 명확하게 나누게 됨(직관적으로 UseCase가 할 행동에 대해 예측 가능)
• 기능에 따른 클래스 분리는 테스트를 용이하게 함
• 협업할 경우 소스의 일관성을 기대할 수 있음

 

 

 

참조 : 

https://velog.io/@sery270/Android%EC%9D%98-Clean-Architecture%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90-n9ihbaj4

https://velog.io/@sysout-achieve/Android-Clean-Architecture