지난 포스팅에서는 간략하게 Clean Architecture에 대해 알아보고, 이를 적용할 시 어떠한 장점을 갖는지만 정리를 해봤다.

이번에는 4개의 계층으로 나뉘어진 아키텍처에서 각각의 계층이 어떠한 역할을 하는지 알아보려고 한다.

Clean Architecture

좋은 코드란? 가독성이 좋은 코드? 테스트 커버리지가 높은 코드?

여러가지 기준이 있겠지만, 그 중 하나인 유지보수하기 쉬운 코드(변화에 잘 대응할 수 있는 코드)또한 좋은 코드의 기준 중 하나일 것이다.

유지보수하기 쉬운 코드는 변화에 따른 코드 변경이 적다는 것일 가능성이 높다. 그러기 위해서는 코드가 잘 분리되어 있어야 한다. 그 방법 중 하나로 Clean Architecture를 예로 들 수 있고, 우리가 알아봐야 할 개념이다.

  • 위의 그림은 Robert Martin이 소개한 Clean Architecture 다이어그램이다. 양파 모양의 4개의 Layer가 존재한다.
  • 가장 바깥쪽의 Frameworks & Drivers가 사용자와 접점에 있는 Presentation이다.
  • 가장 안쪽의 Entities가 사용자가 실제로 생각하는 개념의 단위이다.
  • Clean Architecture는 실제로 서버쪽 내용이라고 한다. 하지만, 안드로이드에서도 이 개념을 적용시켜 UI를 독립시키고 데이터베이스를 분리시키고 외부적인 설정에 독립적인 구조를 적용하여 프레임워크에 의존적이지 않은 독립적인 코드를 짤 수 있다.

android에서 Clean Architecture를 적용할 때, 4개의 레이어로 분리하면 위와 같은 사진으로 적용된다.

4 Layer

안드로이드 계층을 4개로 나눌 수 있다.

  • 사용자에게 보여지는 로직과 관련된 Presentation Layer
  • Network를 포함한 데이터를 가져오는 Data Layer
  • 사용자의 use case로 분리되는 Domain Layer
  • 사용자의 개념을 정의하는 Entity Layer

위의 4개의 레이어 간의 의존성은 안쪽으로만 발생해야 한다. 가장 하단부의 레이어일수록 의존성이 낮아야 한다.

Presentation Layer는 Data Layer를 알지만, Data Layer는 Presentation Layer를 몰라야 한다. 이 덕분에 맨 아래 Entity Layer는 순수한 Java 또는 Kotlin 모듈이 될 수 있고 안드로이드에 의존성을 가질 수도 있고 안드로이드 의존성을 가지지 않을 수도 있다. (즉, 의존성이 적기 때문에 다른 플랫폼에서도 사용이 가능하다.)

이러한 분리를 통해서 어떤 데이터베이스에 저장될지, 어떤 뷰에 보일지 고민하지 않고 Entity를 작성할 수 있고, 이에 대한 유스 케이스로 Domain Layer를 작성할 수 있다. 또한, 트랜잭션을 가져오는 것은 Data에서 어떻게 보여줄 것인지를 Presentation에서 정할 수 있다.

각 Layer별 설명.

1. Entity Layer

  • Entity는 순수한 Java 또는 Kotlin 모듈이므로 안드로이드와 의존성이 없다. 안드로이드에서만 사용하는 것이 아니라고 생각하고 작성해야 한다.
  • 다른 플랫폼의 같은 서비스를 만든다면 Android, iOS, Server 모두 같은 이름과 타입을 사용하는 동일한 형태여야 한다.
  • 따라서 넘기는 데이터를 Parcelable 등으로 정의하는 등의 행위는 삼가해야 한다.
  • 정리하자면, 사용자가 생각하는 형태대로 도메인(비즈니스 로직)에서 파생되는 개념을 표현한다.

2. Domain Layer

  • Domain Layer도 순수한 Java나 Kotlin 모듈이다.
  • 실제로 사용자가 하는 일련의 행동들, 즉, 유스 케이스를 적용하는 것인데, 이 역시 안드로이드에 의존할 필요가 없기 때문이다.
  • 유스 케이스를 구성할 때는 데이터베이스가 무엇인지 뷰가 어떤 것인지 고민하지 않고, 도메인에서 정의한 적당한 레포지토리를 이용하여 구축하므로 코드가 사고의 흐름처럼 구성될 수 있다.

3. Data Layer

  • Data Layer에서 하는 한 가지 일을 고르자면, Domain Layer를 알고 있으므로 Domain Layer에 정의된 Repository를 실제로 구현하는 것이다.
  • 또한 여기에서는 Data Source에 의존성이 생기므로, 안드로이드 의존성이 생길 수 있다.

4. Presentation Layer

  • 마지막 최상위 레이어인 Presentation Layer는 UI 레벨에서의 처리이고 Android 의존성이 높다. MVP 구조를 사용한다면 presenter가 생성되는 시점에 유스 케이스를 주입받을 수 있는 구조로 작성한다.
  • 이처럼 작성하게 될 시에 테스트하기에 좀 더 편리하다.

참고