[안드로이드] 클린 아키텍처 정리

오늘 알아볼 것은 클린 아키텍처이다. 요즘 책을 읽으면서 공부 중인데 클린 아키텍처에 대한 이야기도 있어서 내가 정리할 겸 글도 쓴다.

아직까지 응용 부분은 힘든 점이 있어서 이번 글에 응용까지 담기는 어려울 것 같고 다음 글에 클린 아키텍처를 도입하여 다시 한번 설명해 주겠다.

 

클린 아키텍처

클린 아키텍처는 로버트 C. 마틴에 의해 만들어진 철학으로, 소프트웨어의 관심사를 계층별로 분리하는 소프트웨어 디자인 철학이다.

원 바깥에서 원 안으로 들어갈수록 추상화 수준이 높아짐.

 

이 클린 아키텍처의 주요 원칙은 코드의 종속성이 외부로부터 내부로 의존한다는 것이다.

내부 계층의 코드는 외부 계층의 기능을 알 수 없다. 외부 계층에 존재하는 변수, 함수 및 클래스( 모든 엔티티 )는 안쪽 계층에서 다시 등장이 불가능하다. 데이터 형식도 계층 간에 별도로 유지하는 것이 좋다고 한다.

 

가장 가운데 원(Entities)은 가장 추상적인 영역이다. 비즈니스 로직을 포함하고 사용 중인 플랫폼이나 프레임워크에 의존해서는 안 된다. 외부 원은 네트워크 및 데이터베이스의 접근처럼 플랫폼에 특정한 구체적인 구현 세부사항이 포함된다. 

 

클린 아키텍처를 사용했을 때의 장점은 계층을 분리하고 계층 간의 의존성을 단방향으로 만들기 때문에 코드의 재사용성이 용의 해지며, 유닛 테스트가 쉬워진다는 점이 있다.

 

기본적인 의존성 규칙은 변함이 없다. 내부 계층은 외부 계층을 알면 안 된다. 이것만 잘 지키면 계층은 몇 개로 나누어도, 어떻게 나누어도 크게 상관없다. 만약 계층이 더 필요하다면 나누어서 관리하면 된다. 의존성 규칙만 잘 지키면 되며, 항상 바깥쪽에서 안쪽으로 참조하며, 안쪽 계층으로 진입할수록 추상화와 캡슐화의 수준이 높아진다.

 

 

이제 각 계층에 대해 자세히 알아보자.

Entities ( Enterprise Business Rules )

엔티티는 *전사적 비즈니스 규칙을 캡슐화한다. ( 데이터의 구조나 메서드를 포함하는 객체 )

전사적으로 많은 다른 애플리케이션 사이에서 사용될 수 있다.

 

하나의 애플리케이션을 위한 엔티티라면 애플리케이션의 비즈니스 로직을 담고, 가장 일반적이고 상위 수준의 규칙들을 캡슐화한다. 또 외부에서 무언가 변경되었을 때 가장 최소한의 변경 사항을 가져야만 한다.

 

예를 들자면, 화면의 이동, 보안과 관련된 내용이 변경되었을 때도 엔티티 계층은 영향을 받으면 안 된다.

 

네트워크나 데이터베이스와 관련된 클래스를 작성할 때 POJO와 같은 데이터 클래스를 작성하는데, 이러한 클래스들이 이 계층에 속한다고 볼 수 있다. 이러한 데이터 클래스들은 순수한 자바 또는 코틀린 코드일 때 유닛 테스트가 수월하다.

또 이 클래스들은 안드로이드 애플리케이션과 관련된 코드를 포함해서는 안 된다.

 

* 전사적이란? : 기업 전체, 회사 전반에 관련되는, 또는 그러한 것. 영어로는 Enterprise

Use Cases ( Application Business Rules )

유스 케이스 계층에서는 애플리케이션과 관련된 비즈니스 규칙을 포함하고 시스템의 모든 유스 케이스 구현체들을 캡슐화한다. 이러한 유스 케이스들은 엔티티로부터의 데이터 흐름들을 관리하고 유스 케이스의 목적을 달성하도록 엔티티에 넓고  전사적인 비즈니스 규칙의 사용을 가르침. 관심사를 분리하여 계층을 분리해 이 계층은 엔티티에 영향을 미치지 않으며, UI나 프레임워크 같은 외부 계층에서도 영향을 받지 않음.

 

안드로이드에서는 Model, Repository, Executor 등과 관련된 내용이 이 계층에 속함.

• Model : 데이터베이스의 질의나 네트워크 요청 등의 비즈니스 로직 수행
• Repository : 내부 DB 접근, 저장 또는 원격 서버의 데이터를 요청. 일반적으로 인터페이스이며 인터페이스를 구현해 외부 계층의 연결을 느슨하게 함.
• Executor : Repository나 Model과 관련된 작업이 백그라운드에서 작업을 수행할 수 있도록 작업 스레드 관리 및 제공

 

Interface Adapters( Presenters )

이 계층은 유스 케이스나 엔티티로부터 얻은 데이터를 가공하는 계층이다. 비즈니스 로직을 수행하여 원하는 결과값을 얻어 UI에 표현하려고 적당한 형식으로 데이터를 변경한다.

아키텍처 디자인 패턴에서 흔히 말하는 Presenter, View, ViewModel, Controller 같은 관심사가 여기에 속한다.

반대로 UI로부터 얻은 데이터를 내부 DB나 원격 서버에 전송할 때도 이 계층에서 데이터를 가공하여 전달.

 

이 계층의 목적은 비즈니스 로직과 프레임워크 코드를 자연스럽게 연결하는 것이다.

 

 

Frameworks와 Drivers ( UI )

가장 바깥쪽 계층으로 일반적으로 안드로이드에서 UI와 관련된 액티비티, 프레그먼트, 인텐트 전달 그리고 데이터에 접근하고 저장하는 데이터베이스, 콘텐츠 프로바이더가 포함되며 Retrofit과 같은 네트워크 관련된 프레임워크 코드가 이곳에 속한다.

 

 

이렇게 오늘 클린 아키텍처에 대해 개념만 살짝 살펴보았다.

이 클린 아키텍처는 SOLID 원칙을 잘 따른 일종의 모법 패턴이다. 그렇기에 클린 아키텍처에 정답은 없다.

상황에 따라 조금씩 다른 형태를 가질 수 있으나 원칙은 변하지 않기 때문이다.

그러니 원칙만 잘 따르면 많은 문제점을 해결하고 더 나은 산출물을 만들 수 있다.

 

다음에는 직접 구현해본 것을 들고 오도록 하겠다.