[Clean Architecture] 02-안드로이드 클린 아키텍처

3. 클린 아키텍처

• 소프트웨어의 관심사를 계층별로 분리하는 소프트웨어 디자인 철학
• 주요 원칙 : 코드 종속성이 외부로부터 내부로 의존
  • 내부 계층 코드는 외부 계층의 기능을 알 수 없음
  • 외부 계층에 존재하는 변수, 함수, 클래스 등 모든 엔티티는 안쪽 계층에서 다시 등장 불가
  • 데이터 형식도 계층 간에 별도로 유지하는 것이 좋아

• 가장 추상 적인 영역은 가장 가운데 있는 녀석
• 비즈니스 로직을 포함.
• 플랫폼, 프레임워크에 의존하면 안됨

 

• 외부 원은 네트워크, 데이터베이스 접근 등 플랫폼에 특정한 구체적 구현 세부사항이 포함됨.
• 내부로 갈 수록 추상화 캡슐화 수준이 높아짐

 

• 장점 : 계층을 분리. 계층 간의 의존성을 단방향으로 유지. 코드의 재사용성 용이 및 유닛 테스트가 쉬워짐

 

Entities

• 전사적 비즈니스 규칙 캡슐화
• 데이터 구조, 매서드를 포함
• 가장 일반적이고 상위 수준의 규칙 캡슐화 할것
• 외부에서 변화가 나면 가장 최소한의 변경 사항을 가져야함
• 안드로이드 애플리케이션과 관련된 코드를 포함해서는 아니된다. (순수 코틀린 or 자바 코드 사용 권장)

Use Cases

• 애플리케이션과 관련된 비즈니스 규칙 포함, 시스템의 모든 유스 케이스 구현체 캡슐화
• 엔티티로 부터 데이터 흐름 관리
• 유즈 케이스 목적 달성을 위해 엔티티에 비즈니스 규칙 사용을 가르침
• 엔티티 또는 UI, 프레임워크에 영향을 받지 않음
• 안드로이드 에서
  • Model : 데이터베이스 질의, 네트워크 요청 등 비즈니스 로직 수행
  • Repository : 내부 DB 접근, 원격 서버 데이터 요청 (interface)
  • Executor : Repository, Model 관련 작업을 백그라운드에서 실행되도록 작업 스레드 관리 및 제공
  • 등

 

Interface Adapters

• 유즈케이스, 엔티티로부터 얻은 데이터 가공
• UI에 바인딩
• 흔히 말하는 Presenter, View, ViewModel, Controller 같은 관심사가 여기 속함
• UI에서 얻은 데이터를 내부 DB 또는 원격 서버로 올릴 때도 이 계층에서 데이터를 가공하여 전달
• 목적 : 비스니스 로직과 프레임워크 코드를 자연스럽게 연결

 

Frameworks와 Drivers

• 안드로이드에서 UI 관련하여 액티비티, 프래그먼트, 인텐트 전달 그리고 데이터에 접근/저장하는 데이터베이스, 콘텐츠 프로바이더가 포함
• Retrofit 같은 네트워크 관련 프레임워크 코드가 여기 속함

 

결론

• 관심사를 분리하면 SW가 방해받지 않고 집중해야할 문제에 집중할 수 있음
• SOLID 원칙을 따른 일종의 모범이되는 패턴
• 꼭 위처럼 해야하는 것이 정답은 아닐 수 있음. 코딩에 정답은 없다.

 

해당 글은 '아키텍처를 알아야 앱 개발이 보인다' 를 공부하며 요약 정리한 글 입니다.