Clean Architecture

Clean Architecture

 

좋은코드란 무었을까요?  가독성이 좋은코드 ? 테스트커버리지가 높은코드 ? 

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

유지보수하기 쉬운코드는 변화에따른 코드변경이 적다는 것일것입니다. 

그러기 위해서는 코드가 잘 분리되어있어야 합니다.

그방법중 하나인 Clean Architecture에 대하여 알아보도록 하겠습니다.

Clean Architecture 알아보기

Robert Martin이 소개한 CleanArchitecture 다이어그램입니다.

양파모양의 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로 나눕니다.

이 레이어 간의 의존성은 안쪽으로만 발생하여야 합니다. 가장 하단부의 레이어일 수록 의존성이 낮아야합니다.

Presentation Layer는 Data Layer를 알지만 , Data Layer는 Presentaion Layer를 몰라야 합니다.

이 덕분에 맨 아래 Entity Layer는 순수한 Java 또는 Kotlin 모듈이 될 수 있고 (안드로이드에 의존성을 가질수있고) , 

안드로이드에 의존성을 가지지 않을수도 있습니다.(다른플랫폼에서도 사용가능, 의존성이 적기 때문)

 

이러한 분리를 통해 어떤 데이터베이스에 저장될지, 어떤 뷰에 보일지 고민하지 않고 Entity를 작성할 수 있고, 이에 대한 유스케이스로 

Domain Layer를 작성할 수 있습니다. 또한 트랜잭션을 가져오는 것을 Data에서 어떻게 보여줄 것인지를 Presentation에서 정할 수 있습니다.

 

 

 

Entity Layer

엔티티는 순수한 Java 또는 Kotlin모듈 이므로 안드로이드와 의존성이 없습니다.

안드로이드에서만 사용하는 것이아니라고 생각하고 작성해야 합니다.

(다른플랫폼의 같은서비스를 만든다면 Android, iOS ,Server모두 같은 이름과 타입을 사용하는 동일한 형태여야 합니다)

따라서 넘기는 데이터를 Parcelable등으로 정의하는 등의 행위는 삼가해야합니다.

정리하자면 사용자가 생각하는 형태대로 도메인(비즈니스로직)에서 파생되는 개념을 표현합니다.

 

Domain Layer

도메인 레이어도 순수한 Java나 Kotlin 모듈 입니다.

실제로 사용자가 하는 일련의 행동들 즉 유스 케이스를 적용하는 것인데, 이 역시 안드로이드에 의존할 필요가 없기 때문입니다.

유스케이스를 구성할 때는 데이터베이스가 뭔지 뷰가 어떤것인지 고민하지 않고, 도메인에서 정의한 적당한 

레파지토리를 이용하여 구축하므로 코드가 사고의 흐름처럼 구성될 수 있습니다.

 

Data Layer

Data Layer에서 하는 한가지 일을 고르자면, 도메인레이어를 알고 있으므로 

도메인레이어에 정의된 Repository를 실제로 구현하는 것입니다.

또한 여기에서는 Data Source 에의 의존성이 생기므로, 안드로이드 의존성이 생길 수 있습니다.

 

 

Presentation Layer

마지막 최상위 레이어인 프레젠테이션 레이어는 UI레벨에서의 처리이고 Android 의존성이 높습니다.

Mvp 구조를 사용한다면 presenter가 생성되는 시점에 유스 케이스를 주입받을수 있는 구조로 작성합니다.

이처럼 작성하게 될 시에 테스트하기에 좀더 편리하게 됩니다.