안드로이드 앱개발에서의 클린아키텍쳐

먼저 이상적인 소프트웨어란 무엇일까요?

개인적으로 이상적인 소프트웨어는 두가지 조건을 만족시켜야 한다고 생각합니다.

 

1. A라는 클래스를 변경해도 B라는 클래스를 변경할 필요가 없어야한다.

2. A라는 기능을 테스트할때 B라는 기능은 테스트에 영향을 끼치거나, 영향을 받지 않아야한다.

 

이 조건을 충족하기 위해서는 소프트웨어의 구조를 잘 짜야합니다.

여기서 클린아키텍쳐가 쓰입니다.

 

클린아키텍쳐란?

클린아키텍쳐는 소프트웨어 아키텍쳐의 한 종류입니다.

그 목적은 소프트웨어를 여러개의 계층으로 나눠서 유지보수성과 테스트 용이성을 올리기 위함입니다.

각 계층은 따로따로 테스트가 가능하고, 한 계층의 변경사항이 다른 계층에 영향을 주지 않습니다.

 

클린아키텍쳐를 설명하는 너무나도 유명한 그림이다.

 

클린아키텍쳐를 구현하기 위해서는 아래 두가지만 지키면됩니다.

 

1. 각 계층을 이해한다.

2. 의존성을 원의 바깥에서 안쪽으로만 향하게 한다.

 

먼저, 이 글은 깃허브에 올려둔 제 개인프로젝트를 바탕으로 쓰여졌습니다.

따라서 일반적인 클린아키텍쳐에서 말하는 용어와는 차이점이 있음에 유의하시기 바랍니다.

 

 

 

1. Data Layer

API를 통해 데이터를 주고받는 레이어입니다.

 

 

Repository

Domain Layer의 Repository 인터페이스를 구현하는 Repository입니다.

DataSource로부터 데이터를 받는 API를 제공합니다.

DataSource가 Local이든 Remote이든 Repository를 이용하는 클래스는 신경쓸 필요가 없습니다.

 

Entitiy

로컬 혹은 리모트 저장소에서 받은 데이터를 말합니다.

즉, API가 응답하는 데이터의 구조와 일치하는 데이터 클래스입니다.

가공되지 않은 데이터라고도 할 수 있습니다.

 

Mapper

Entitiy -> Data로 형을 변환해주는 유틸성 클래스입니다.

DataSource로 부터 받은 데이터는 Entity 형입니다.

하지만 Repository가 외부로 제공하는 데이터는 Domain Layer의 Data 클래스이므로

DataSource로 부터 Entity를 받은 뒤, 외부에 제공할때는 Mapper를 거쳐 Data 형태로 제공해야합니다.

 

 

2. Domain Layer

앱의 세부적인 명세를 나타냅니다.

요구사항을 처리하는 usecase가 핵심입니다.

 

 

Data

앱의 요구사항에 따라 쓰기 좋게 Entity를 가공한 데이터 클래스입니다.

API에서 받아온 데이터인 Entitiy는 그대로 쓸 수도 있지만, 불필요한 데이터가 포함되있는 경우도 있습니다.

따라서 쓰기 좋게 가공한 데이터가 이 클래스입니다.

 

Repository

API로부터 데이터를 가져오는 역할을 합니다.

다만, 여기서는 인터페이스입니다.

Domain Layer는 API와의 통신을 담당하고 있지 않기때문에 외부의 Repository를 사용해야합니다. 

API와의 통신을 담당하는건 Data Layer입니다.

Domain Layer가 Data Layer의 Repository를 사용하기 위해선 어떤 중간다리가 필요할텐데, 그것이 바로 이 Repository 인터페이스입니다.

Repository의 뼈대는 Domain Layer에서 정의하고, Data Layer에서는 그 뼈대에 맞춰 Repository를 구현합니다.

이렇게하면 Domain Layer는 이 Repository를 구현하는게 뭐가됬든, 그저 Repository 인터페이스만 보고 Repository를 사용할 수 있게 됩니다.

 

Usecase

앱의 요구사항을 처리하기 위한 클래스입니다.

보통은 Repository를 사용하여 외부나 내부에서 데이터를 가져오고, 그 데이터를 처리해서 결과를 리턴합니다.

 

 

3. Presentation Layer

화면을 담당하는 레이어입니다.

 

 

Data

앱에서 직접적으로 쓰이는 데이터를 말합니다.

Domain Layer에서의 Dataclass 를 직접 사용할 수도 있지만 그렇게되면 Domain Layer의 변경이 Presentation Layer에 영향을 끼치게 됩니다. 그것이 상관이 없다고 한다면 이 데이터는 정의하지 않아도 됩니다.

 

Mapper

Domain Layer의 data를 Presenter의 data로 바꿔주는 클래스입니다.

 

ViewModel

여기서 Domain Layer의 Usecase를 사용합니다.

 

 

 

* 각 Layer마다 dataclass가 있어서 중복이된다고 생각하실수도 있습니다. 하지만, 로버트 C 마틴은 가짜중복과 진짜중복을 구분해야한다고 말합니다. A와 B가 중복일때 각각이 변경되는 이유와 상황이 다르다면 그것은 가짜중복이라고 합니다. 이런 점에서 볼때, 각 레이어의 dataclass 들은 각 레이어의 상황에 따라 각자 다른 이유로 변경될 수 있으므로 가짜중복이라고 할 수 있습니다.