[Android] 클린아키텍처

! 테스트가 용이하고 유지 보수하기 쉽게 구조를 구성하고 싶어서 이를 적용할 수 있는Clean Architecture를 사용하기 위해 공부한 내용을 정리해 봤다.

1. 클린 아키텍처란?

클린 아키텍처는 Uncle Bob이라고 알려진 Robert C.Martin이 2012년에 제시한 개념이다. Uncle Bob의 책을 직접적으로 읽어보지는 않았지만 그의 블로그를 들어가서 Clean Architecture에 대해 적어 놓은 글을 보면 제일 첫 번째로 아래와 같은 그림이 나왔다. 설명에 대해서는 한글번역 이 분이 번역해주신 내용을 읽어 봤다.

위 그림에서와 같이 클린 아키텍처는 4가지 계층으로 나뉘어져 있다. 이렇게 계층을 나눈 이유는 바로 관심사의 분리를 위해서이다.

관심사 분리는 간단하게 말해서 여러 가지를 동시에 신경쓰기 보다 따로 따로 분리해서 생각하자는 것이다.

관심사 분리를 할 경우 코드가 단순화 되며 유지보수의 더 높은 수준의 자유를 가질 수 있다.

잠깐 위의 동심원에 대해 설명하자면 소프트웨어의 각기 다른 영역을 나타내고 있다. 바깥쪽으로 향할수록 고수준의 소프트웨어가 된다. 바깥쪽의 원은 메커니즘이라고 부르며 안쪽에 있는 원을 정책이라고 부른다.

다음으로 의존성 규칙에 대한 이야기가 있다. 이 규칙은 클린 아키텍처를 기능하게 하는 중요한 것으로 소스 코드가 위의 동심원 안쪽을 향해서만 의존할 수 있다. 즉 안쪽의 원은 바깥쪽 원에 대해 전혀 알지 못하도록 코드를 작성해야 하는 것이다. (내가 해석했을 때 의존이라는 말을 '참조'하는 것으로 해석했다.')

2. 안드로이드 용 클린 아키텍처

Uncle Bob이 작성하신 글에는 실제 안드로이드에서 사용하는 아키텍처 구조와 용어도 좀 다르기 때문에 검색을 했을 때 안드로이드에 맞춘 설명들이 있어서 그것들을 참고해서 따로 공부를 해봤다.

참조 : https://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc

위의 그림과 같이 presentation Layer, Domain Layer, Data Layer로 총 3가지 계층으로 나눌 수 있다. 의존성의 경우 Presentation -> Domain -> Data 방향이다. 즉 Presentation이 바깥 원을, Domain, Data순으로 안쪽 원을 차지하고 있다.

2 - 1 presentation Layer

UI, Presenter 및 VIewModel을 포함하고 화면과 입력에 대한 처리 등 UI와 직접적으로 관련된 부분을 담당

즉 UI를 출력하여 사용자에게 제공하고, 입력을 받아서 전처리 한 후 Domain 계층으로 넘긴다. 추후에 다시 Domain 계층에게 결과값을 받아 ViewModel 단에서 처리한 후에 UI업데이트를 진행하는 방식이다.

추가로 DI(의존성 주입)의 경우에도 presentation 계층 단에 속할 수 있다.

2 - 2 Domain Layer

비즈니스 로직을 포함하여 Model과 UseCase가 여기에 포함 됨

• 비즈니스 로직이란?

하나의 프로젝트나 프로그램 중 업무와 관련된 처리를 하는 일부분으로 사용자가 원하는 자료의 가공 부분을 의미한다.

• UseCase란?
  Clean Architecture를 공부하면서 UseCase에 대해서 처음 들어봤다.
  1개 이상의 Repository를 받아서 비즈니스 로직을 처리하는 부분이다. UseCase는 그래서 보통 한개의 행동을 담고 있고, 이름만 봤을 때 '아 이건 무슨 기능을 담당하겠구나'라고 유추가 가능하도록 작성해야 한다.
  
  
  추가적으로 Use Case 작성시 다음과 같은 사항들을 주의해야한다.
  
  UseCase는 Presentation 계층의 UI에서 한 이벤트나 동작에 의해 호출되는 방식으로 설계해야 한다.
  
  Domain 계층에서 정의한 Repository를 주입한다.

Domain 계층에서 중요한 점은 presentation, data 계층과 어떤 의존성도 갖지 않아야 한다는 점이다.

비즈니스 로직을 위한 Repository의 내부 실제 구현은 데이터 계층으로 위임하고 여기서는 Repository Interface를 생성한다.

2 - 3 Data Layer

Repository 구현체, Cache, Room, Dao, Model의 서버 API를 포함하며 Mapper 클래스도 포함

실제 서버나 DB와 연동되어 값을 보내거나 가져오는 역할을 진행한다. 서버와 DB의 DataSource를 담당하고 이 데이터를 Repository 패턴을 통해 더 의미있게 가공하여 제공된다.(Repository 패턴에 대한 내용도 정리 예정)

예제 코드의 경우 위의 정리한 개념을 통해 작성할 예정