[Android] Clean Architecture

잘못된 정보나 수정할 사항 or 피드백은 언제든 환영합니다.

개발 공부를 하면서 굉장히 자주 만나는 익숙하지만 친하지 않은 용어가 있다.
Clean Architecture...(잘 안친해짐, 낯가림)

클린아키텍처와 친해지기 위해 왜 적용하는지, 그때 이점은 뭐가 있고, 어떤 비용이 생기는지에 대해서 정리하고자 한다. (Clean Architecture 책 정독 후 업데이트 예정)

클린아키텍처란?

: Clean Architecture란 코드를 잘 분리하기 위한 기법
코어 비즈니스 로직을 바뀔 수 있는 모든 것으로부터 분리하여 제품을 유연하게 구성하려는 목표를 가짐

왜 적용하는가?

• 프레임워크에 독립적임
  : Clean Architecture의 경우 일부 기능이 포함된 라이브러리, 프레임워크에 의존하지 않음
• UI에 독립적임
  : 다른 시스템 변경없이 UI를 쉽게 변경할 수 있음
  -> 독립적이기 각 Layer의 변경에도 영향을 적게 받음. 시스템의 추가 및 변경이 필요한 시기에 유연한 대응이 가능함

ref. Clean Archtecture 2012 Uncle Bob

• 그림의 안쪽으로 갈수록 의존성을 갖지 않음(반대 방향의 의존성을 가져야할 경우 interface를 사용해야함
• 안쪽계층은 바깥계층에게서 독립적으로 존재해야함
• UseCase를 중심으로 서비스를 개발해야함

각 Layer에 대한 설명

Entity

• 유저가 해당 앱에서 기대하는 어떠한 기능과 개념을 정의한 Layer
• 순수 모듈, 프레임워크단에 대한 의존성이 없음

Domain

• 사용자가 앱을 사용할 때 생각하는 일련의 개념 단위
• 앱에서 일어날 동작(UseCase)을 작성
• Domain 레이어에서 Repository Interface 정의

Data

• Data 레이어는 Domain 레이어에서 설계한 Repository를 실제 구현
• DataSource 의존성을 가짐
• Data를 호출하는 라이브러리(내부DB, Network 라이브러리 등)에 대한 의존성을 갖게 됨

Presentation

• 화면 UI/UX를 정의하는 레이어
• View, ViewModel 등이 구현되며 안드로이드 의존성을 갖게 됨

클린아키텍처의 장,단점

장점

• 클래스 집중화로 유지보수 쉬워짐(이슈발생 시 예측 용이)
• 내부 레이어가 사용자 인터페이스로부터 독립됨
• 내부 레이어가 다른 외부관련 요소와 독립됨
• 모든 것이 계층화, 각각 책임이 명확하여 클린아키텍처를 이해한 사람은 비교적 빠르게 코드 파악가능

단점

• 클린 아키텍처를 구현하려면 별도의 모듈이 필요하고 새로운 인터페이스를 구현하는 과정에서 초반에 비교적 큰 비용 발생

Use Case

: 어플리케이션이 수행하고자 하는 핵심적인 기능(우리가 만드는 애플리케이션에서 절대로 바뀌지 않을 기능 - 기획이 바뀌면 만드는 제품이 바뀌는 것이기 때문에 당연히 바뀜)
클린아키텍쳐의 핵심은 코어 비즈니스 로직을 바뀔 수 있는 모든것으로부터 분리하자라는 생각

UseCase를 사용하는 이유

• 사용자가 수행하려는 기능 명확하게 정의
• UseCase로 시스템이 수행해야하는 행위를 정의 -> 프로젝트의 구성요소를 UseCase내에서 사용하여 목적을 달성 -> 각 Layer의 격리 도움

장점

• UseCase를 사용함으로써 ViewModel에 로직이 집중되는 것을 피할 수 있음
• 다른 ViewModel에서 같은 로직을 사용할 경우 재활용가능
• 각 기능을 명확하게 나누게 됨(직관적으로 UseCase가 할 행동에 대해 예측 가능)
• 기능에 따른 클래스 분리는 테스트를 용이하게 함
• 협업할 경우 소스의 일관성을 기대할 수 있음