[안드로이드] Clean architecture

Chloe Choi·2021년 4월 7일

안드로이드

목록 보기

11/17

배경

TODO App, Weather App ... 이런 앱의 메인 기능을 뭘까? TODO, Weather이다. 프로그램의 핵심기능을 Use case라 하자. 이런 앱을 만들때 어떻게 설계해야할까?

Use case를 중심으로 설계해야 한다.

Use case는 비즈니스 로직을 담는데, 이게 바뀌지 않는 이상 Use case를 수정하는 일은 없도록 해야한다. 따라서, 비즈니스 로직을 바뀔 수 있는 모든것으로부터 분리해야한다!

예를 들어, Buy Goods라는 Use case가 있다.
1. 구매자의 구매요청
2. 판매자가 구매요청 정보 수집
3. 판매자가 구매자에게 정보를 줌(가격, 배송일자 등)
4. 구매자가 구매승인
...
위 단계 중 어느 과정에도 platform, DB process 등 이런 정보는 전혀 없다. 이렇게 관심사를 분리해 Use case에 집중하는 "클린 아키텍처"에 대해 알아보자

클린 아키텍처

How

일단 설계의 중심이 될 Use case가 있다. 그리고 data 및 재사용 가능한 로직을 포함한 Entity를 만든다. 그럼 Application, DB 등은 Use case와 Entity에 직접적으로 접근하면 될까?

안된다. 그렇게 하면 외부세계(Application, DB 등)의 변경이 Use case에 영향을 미친다. 따라서, Use case와 외부세계 사이를 느슨하게 결합시켜주는 interface가 필요하다. 이걸 Interface adapter라고 하자.

이렇게 구성하면 비즈니스 로직을 모든것으로부터 분리했다고 할 수 있을까? 비즈니스 로직이 외부세계에 대한 참조를 갖고있다면? 그래서 의존성 법칙(The Dependency Rule)을 적용한다. 이 법칙은 위 Frameworks & Drivers -> Interface adapters -> Use cases -> Entities 방향으로 의존할 수 있다는 법칙이다. 근데 개발하다보면 꼭 그 반대로 호출(내부 -> 외부)이 필요한 상황이 있다. 그런 경우엔 외부클래스의 상위타입인 인터페이스를 둬(DIP) 이를 통해 의존성을 주입하는 방식으로 해결한다. 이렇게 Crossing boundaries 방식으로 구현하게 되면 저수준(외부)의 세부사항을 알 필요 없고 변동사항에도 영향을 받지 않게 된다!

What

ref. 도서출판 인사이트

클린 아키텍처란, 아키텍처의 청사진으로 모바일부터 백엔드까지 모든 소프트웨어에 일반적으로 필요한 내용을 담고 있으며, 각 계층을 어떻게 나누고 어떤 요소로 구성할 것인가에 대한 원칙들을 알려준다.

엔티티: 가장 일반적인 비즈니스 규칙(재사용 가능한 로직)을 캡슐화
유스케이스: 특정 앱의 비즈니스 규칙. 시스템이 어떻게 자동화 될 것인지를 정의하고 앱의 행위를 결정. 프로젝트 레벨의 엔티티를 사용해 유스케이스의 목적을 달성 👉 DB, Framework, UI로부터 격리
인터페이스 어댑터: 번역기 역할을 수행. 엔티티 및 유스케이스에서 편리한 방식 <-> DB 및 앱에 적용할 방식
프레임워크와 드라이버: App, DB, HTTP Client 등으로 구성(코드 외 외부세계). 자주, 쉽게 변경될 수 있는 부분 👉 stable 한 유스케이스, 엔티티와 확실히 분리가 되어야 함