What is Clean Archtecture?
클린 아키텍처는 Robert C. Martin에 의해 만들어졌으며 그의 블로그 Uncle Bob에서 소개되었으며, 관심사를 계층별로 분리하는 소프트웨어 디자인 철학이다. 클린 아키텍처의 주요 원칙은 코드 종속성이 외부로부터 내부로 의존한다는 것이다. 내부 계층의 코드는 외부 계층의 기능을 알 수 없다. 외부 계층에 존재하는 변수, 함수 및 클래스 (모든 엔티티)는 안쪽계층에서 다시 등장할 수 없다. 데이터 형식도 계층간에 별도로 유지하는 것이 좋다.
가운데 원은 가장 추상적인 영역이다. 비즈니스 로직을 포함하고 사용중인 플랫폼이나 프레임워크에 의존해서는 안된다. 외부 원은 네트워크 및 데이터베이스의 접근과 같이 플랫폼에 특정한 구체적인 구현 세부 사항이 포함된다.
클린 아키텍처를 사용했을 때의 장점은 계층을 분리하고 계층간의 의존성을 단방향 만들기 때문에 코드의 재사용성이 용이해지고, 유닛테스트가 쉬워진다.
안드로이드에서는 클린 아키텍처가 어떻게 적용될까?
기본적인 의존성 규칙은 변함이 없다. 내부 계층은 외부 계층은 알면 안된다. 이것만 잘 지키면 계층이 몇개로 나뉘든, 어떻게 나뉘든 크게 상관이 없다. 만약 계층이 더 필요하다면 나누어서 관리하면 된다. 의존성 규칙만 잘 지키면 되며, 항상 바깥쪽에서 안쪽으로 참조하며, 안쪽 계층으로 진입할 수록 추상화와 캡슐화 수준이 높아 진다.
Entities
엔터티는 전사적 비즈니스 규칙을 캡슐화 한다. 데이터의 구조나 메서드를 포함하고 있는 객체이다. 전사적으로 많은 다른 애플리케이션들 사이에서 사용될 수 있다.
하나의 애플리케이션을 위한 엔터티라면 애플리케이션의 비즈니스로직을 담고, 가장 일반적이고 상위 수준의 규칙들을 캡슐화 한다. 외부에서 무언가 변경되었을때 가장 최소한의 변경사항을 가져야만 한다. 예를들어 화면의 이동, 보안과 관련된 내용이 변경되었을 때에도 엔터티 계층은 영향을 받으면 안된다.
네트워크나 데이터베이스와 관련된 클래스를 작성할 때 POJO와 같은 데이터클래스를 작성하는데, 그러한 클래스들이 이 계층에 속한다고 볼 수 있다. 이러한 데이터 클래스들을 안드로이드 애플리케이션과 관련된 코드를 포함해서는 안된다. 그저 순수한 자바 또는 코틀린 코드여야하며, 그래야만 유닛테스트가 수월해진다.
Use Cases
유즈케이스 계층에서는 애플리케이션과 관련된 비즈니스 규칙을 포함하고 시스템의 모든 유즈케이스 구현체들을 캡슐화한다. 이러한 유즈 케이스들은 엔터티로부터의 데이터 흐름들을 관리하고, 유즈케이스의 목적을 달성하기 위해 엔터티에게 넓고 전사적인 비즈니스 규칙의 사용을 가르킨다.
관심사를 분리하여 계층을 분리시켰기 때문에 이 계층은 엔터티에게 영향을 미치지 않으며, 외부 계층으로부터도 영향을 받지 UI 나 프레임워크로부터도 영향을 받지 않는다.
안드로이드에서는 Model, Repository, Executor등과 관련된 내용이 이 계층에 속할 수 있다.
- Model : 데이터베이스의 질의나 네트워크 요청등의 비즈니스 로직을 수행한다.
- Repository : 내부 DB애 접근하거나 저장 또는 원격 서버의 데이터를 요청하는 역할을 한다. 일반적으로 인터페이스이며 인터페이스를 구현하여 외부 계층의 연결을 느슨하게 해준다.
- Executor : Repository나 Model에 관련된 작업들이 백그라운드에서 작업을 수행할 수 있도록 작업 스레드를 관리하고 제공한다.
Interface Adapters
이 계층은 유즈케이스나 엔터티로부터 얻은 데이터를 가공하는 계층입니다. 비즈니스 로직을 수행하여 원하는 결과값을 얻어 UI에 표현하기 위해 적당한 형식으로 데이터를 변경하게 되며, 아키텍처 디자인패턴에서 흔히 말하는 Presenter, View, ViewModel, Controller 같은 관심사가 여기에 속하게 된다. 반대로 UI로 부터 얻은 데이터를 내부 DB나 원격 서버에 전송할때도 이 계층에서 데이터를 가공하여 전달하게 된다.
이 계층의 목적은 비즈니스 로직과 프레임워크 코드를 자연스럽게 연결 시키는 것이다.
Frameworks And Drivers
가장 바깥쪽 계층으로 일반적으로 안드로이드에서는 UI와 관련된 액티비티, 프레그먼트, 인텐트 전달 그리고 데이터에 접근하고 저장하기 위한 데이터베이스, 콘텐트 프로바이더가 포함되며 마지막으로 Retrofit 과 같은 네트워크와 관련된 프레임워크 코드가 이곳에 속합니다. 일반적인 애플리케이션 개발자가 프레임워크 코드를 수정할 일은 많지 않다.
Conclusion
관심사가 분리된 코드를 사용하면 많은 소프트웨어가 방해받지 않고 특정 문제에 집중할 수 있다. 클린 아키텍처는 SOLID원칙을 잘 따른 일종의 모범 패턴이라고 생각한다.
클린아키텍처에 정답은 없다고 생각한다. 상황에 따라 조금씩 다른 형태를 가질 수 있으나 원칙은 변하지 않는다. 원칙만 잘 따르면 많은 문제점들을 해결하고 더 나은 산출물을 만들 수 있는것은 분명하다.
0개의 댓글