클린 아키텍처

클린 아키텍처는 모든 개발자가 관심을 가지고 주목하는 개념이다. 하지만, 다른 개발에 치이고 클린 아키텍처를 구현하는데 들어가는 리소스는 어마한데 비해 앱 사용자 입장에서는 바뀐게 없다고 느끼니 과도하게 시간을 쏟기가 정말 애매한 분야처럼 보인다.

하지만 고객들에게 많은 기능들이 포함된 고품질의 애플리케이션을 제공하기 위해서는 복잡도가 굉장히 높아지게 되고 이에 따라 유지 보수하기 쉬운 코드를 작성할 필요가 생겼습니다. 새로운 기능이 추가되거나 내부 로직이 변경되더라도 유연하게 프로젝트를 관리할 수 있게 구조를 짜야하는 거죠.

클린 아키텍처의 목표

계층을 분리하여 관심사를 분리하는 것!!

 

클린 아키텍처의 4가지 계층

1. Entities

엔티티는 비즈니스 규칙을 캡슐화한다. 메서드를 갖는 객체일 수도 있지만 데이터 구조와 함수의 집합일 수도 있다. 가장 일반적이면서 고수준의 규칙을 캡슐화하 게 된다. 외부가 변경되더라도 이러한 규칙이 변경될 가능성이 적다.

1. Use cases

유스케이스는 Interactor라고도 하며 애플리케이션의 고유 규칙을 캡슐화하며 엔티티로부터의 데이터 흐름을 조합한다. 유스케이스 계층의 변경이 엔티티에 영향을 줘서는 안 되며 데이터베이스, 공통 프레임워크 및 UI에 대한 변경으로부터 격리된다.

1. Interface Adapters (Presenters)

인터페이스 어댑터는 데이터를 Entity 및 UseCase의 편리한 형식에서 데이터베이스 및 웹에 적용할 수 있는 형식으로 변환한다. 이 계층에는 MVP의 Presenter MVVM의 ViewModel 및 게이트웨이 (=Repository)가 포함된다. 즉, 순수한 비즈니스 로직만을 담당하는 역할을 하게 된다.

1. Frameworks & Drivers (Web, DB)

프레임워크와 드라이버는 웹 프레임 웤, 데이터베이스, UI, Http Client 등으로 구성된 가장 바깥쪽 계층이다.

계층을 분리하는 이유

계층을 나누는 이유는 위 클린 아키텍처의 목표라고 적은 것과 같이 관심사를 분리시키기 위해서 이런 아키텍처가 동작하기 위해서는 의존성 규칙을 지켜야 한다. 한마디로 각 분리된 클래스가 한가지 역할만 수행하고 서로 의존을 어떻게 할지 규칙을 정하고 지켜야 한다는 말이다.

여기서 의존성 규칙은 모든 소스코드 의존성은 반드시 외부에서 내부로, 고수준 정책을 향해야 한다. 안드로이드를 예로 들면 비즈니스 로직을 담당하는 ViewModel과 같은 코드들이 DB 또는 Web과 같이 구체적인 세부 사항에 의존하지 않아야 한다.

클린 아키텍처의 이점

• 코드 테스트 커버리지 증가
• 쉽게 패키지 구조 탐색이 가능
• 집중화된 클래스에 따른 프로젝트 유지 관리 증대
• 새 기능을 빠르게 적용 가능
• 이후의 개발에도 안정적인 구현
• 명확한 규율로 전반적으로 따라야 할 베스트

참조

https://leveloper.tistory.com/205

[Android] Clean Architecture in Android

https://youngest-programming.tistory.com/484

[안드로이드] 클린 아키텍처(Clean Architecture) 정리 및 구현