CleanArchitectureForAndroid

안드로이드 샘플 프로젝트를위한 깨끗한 아키텍처

이 프로젝트는 저의 저서 인 Clean Architecture for Android에서 제시된 Clean Architecture의 느슨한 구현입니다. Kotlin에서 작성된 기본 Android 프로젝트입니다. 책에 제시된 주요 원칙과 실제 프로젝트에 적용되는 방법을 보여줍니다.

나는이 프로젝트를 최신 상태로 유지하고이를 사용하여 제 3 자 솔루션을 선택할 때 확장 성 , 테스트 가능성 및 유연성과 같은 아키텍처의 강점을 보여주기 위해 노력할 것입니다.

특징

• 기능 분리
• 레이어 분리
  • UI
  • 프레젠테이션
  • 도메인
  • 데이터
  • 데이터 소스
• 더미 분석
• 항해
• 애니메이션
• 단위 테스트
• 엔드 투 엔드 테스트
• Jetpack Compose의 사용을 보여줍니다
• 흐름을 포함한 코 루틴의 사용을 보여줍니다
• MVVM을 보여줍니다
• Ktlint를 사용한 코드 품질 검사
• Detekt를 사용한 코드 품질 검사
• Konsist를 사용한 아키텍처 일관성 검사
• GitHub 동작을 사용한 연속 통합 (CI)
  • 단위 테스트
  • 계측 테스트
  • 일선

선택

• 간단

  " 여기에 소개 된 복잡성은 과잉입니다! "

  동의합니다. 이것이 최종 프로젝트가된다면 새로운 기능이 추가되지 않을 경우 Clean Architecture는 지나치게 복잡했을 것입니다. 그러나 현실은 모바일 프로젝트가 거의 최종적 이라는 것입니다. 사용자 피드백, 마케팅 요구 사항, 신기술 - 이러한 요소 및 기타 요인은 거의 모든 프로젝트에 지속적인 변화를 초래합니다. 그래서, 이제 너무 복잡해 보일 수있는 것은 변화의 시간이 올 때 우리에게 보상 할 것입니다. 깨끗한 건축이 빛날 때입니다.

  부수적으로 : 어떤면에서, 나는 다른 기술을 도입 하여이 프로젝트를 의도적으로 과도하게 복제했습니다. 목표는 실제 시나리오에서도 프로젝트가 시간이 지남에 따라 하나 이상의 기술 솔루션을 포함시키기 위해 프로젝트가 성장했을 수있는 방법을 보여주는 것이 었습니다. 아키텍처는 여전히 작동합니다.

• 클래스와 매핑 확장 기능으로 매핑하는 사람

  모델간에 매핑 할 때는 몇 가지 옵션이 있습니다. 주요 결정은 Mapper 클래스와 매핑 확장 기능 사이입니다.

  확장 기능은 더 간결하지만 매핑에 사용하면 테스트 프레임 워크 선택이 제한됩니다 (예 : Mockito는 정적 함수를 스텁 할 수 없습니다).

  Mapper 확장 기능을 주입하는 것은 어떻습니까? 우리는 그렇게 할 수 있습니다. 그러나 이것은 간결함의 이점을 거의 완전히 제거합니다. 또한 구현을 더 어렵게 만듭니다.

  그래서 나는 약간 더 많은 장황한 콘크리트 매퍼 클래스를 선택했습니다.

• Google의 아키텍처 구성 요소를 건너 뛸 수 있습니다

  Google 아키텍처 구성 요소의 가장 큰 문제는 안드로이드 세부 사항을 프레젠테이션 계층으로 누출한다는 것입니다. 이것은 프레젠테이션 계층이 진정으로 UI 불가지론이되는 것을 방지합니다.

  아키텍처 구성 요소의 또 다른 문제는 뷰 모델에 너무 많은 책임을 져야한다는 것입니다. 그들은 그것을 소유하지 않은 상태로 유지하여 잠재적 데이터 동기화 버그로 이어집니다.

  이러한 이유로, 여전히 MVVM을 따르는 동안이 프로젝트는 Livedata가 아닌 Kotlin 흐름 에 의존하며 Google이 아닌 순수한 뷰 모델을 구현합니다.

• 조롱 프레임 워크

  Mockito-Kotlin과 Mockk는이 프로젝트에서 각각의 사용이 어떻게 보이는지 보여주기 위해 사용됩니다.

  나의 개인적인 취향은 Mockito-Kotlin 으로 남아 있습니다. 코드를 사용할 때 코드를 읽고 따라갈 수 있습니다. 글을 쓰는 시점에서 각 저장소의 별 수로 판단 할 때 업계는 Mockk에 기대어있는 것 같습니다.

  나는 가짜를 사용하는 것에 대한 질문을 받았다. 나는 가짜를 탐험했고, 그것들이 지나치게 말이 많고 유지하기에는 너무 비싸다는 것을 알았습니다.

• 의존성 주입 프레임 워크

  대부분의 최신 앱인 Dependency Injection (DI)의 중요한 부분은 앱을 구축하는 객체를 얻는 데 도움이됩니다. 또한 범위를 관리하는 데 도움이됩니다. Android 세계에서 가장 인기있는 선택은 Hilt (단검 위에 지어진)와 Koin입니다.

  두 가지 주된 이유가 있습니다 .

  1. 컴파일 시간 안전 - 앱이 시작되기 전에 모든 종속성이 제공된다는 확신을 갖는 것은 큰 시간 절약이며 안정적인 앱을 유지하는 데 도움이됩니다.
  2. 단순성 - 경험, HILT 설정 및 사용 (기본 단검과 달리)은 Koin을 사용하는 것보다 훨씬 쉽습니다. Hilt는 또한 시간이 지남에 따라 더 적은 변화를 소개합니다.

• XML vs Jetpack Compose

  왜 둘 다하지 않습니까? 나는 여전히 Jetpack Compose 와 관련하여 많은 우려가 있습니다. 그럼에도 불구하고 선택된 UI 메커니즘에 관계없이 제시된 아키텍처가 잘 작동한다는 것을 보여주는 것이 중요했습니다. 연습으로, 나는 당신이 프레젠테이션 레이어를 업데이트하지 않고 Compose에서 XML로 또는 그 반대로 UI 계층을 교체하도록 초대합니다.

모래밭

아마존의 안드로이드를위한 깨끗한 아키텍처

깨끗한 코더 블로그의 깨끗한 아키텍처

기여

이 프로젝트에 대한 기여를 환영합니다. 문제를보고하거나 포크를 변경하고 풀 요청을 제기하십시오.

특허

이 프로젝트는 MIT 라이센스의 조건에 따라 배포됩니다. 자세한 내용은 License.md를 참조하십시오.