Clean Architecture 궁금했던 점 살펴보기

Clean Architecture 궁금했던 점 살펴보기

 

 

안녕하세요

이번에는 Clean Architecture에 대한 주의점과 궁금했던 부분에 공부한 내용을 공유해드리려고 합니다.

Clean Architecture에 대한 기본 개념에 대한 설명은 너무 많은 블로그가 존재하기 때문에 생략하고 설명드리겠습니다.

 

 

 

클린 아키텍처는 왜 유지보수에 용이할까?

1. 관심사를 분리함으로써 필요한 계층만 추가, 수정하면 되므로 더 편리합니다.
2. 결합도를 낮추어 수정에 용이합니다. 의존성 주입을 사용해 결합도를 낮추도록 합니다. 이렇게 하면 상위 계층이 하위 계층의 구현으로부터 독립되기 때문에 하위 계층의 변화에 영향을 받지 않습니다. (의존성 역전 원칙)

 

 

 

UseCase가 필요한 이유

• UseCase가 없으면 ViewModel이 비즈니스 로직을 가지고 있어야하는데 그렇게 되면 ViewModel이 너무 비대해지게 됩니다.
• 각 UseCase는 특정한 비즈니스 동작을 담당하여 해당 UseCase에서만 관련된 로직을 처리하도록 하여 단일 책임 원칙을 준수하도록 합니다.

(UseCase를 사용하여 비즈니스 로직을 캡슐화하고 Presentation Layer와 Data Layer 계층을 분리해준다는 특징이 있지만 만약, UseCase가 없으면 Repository가 이를 담당할 것이라 생각하기 때문에 생략합니다.)

 

 

 

Repository 구현부를 DataLayer에서 작성하는 이유

• 위 계층이 하위 계층의 구현으로부터 독립되게 하는 의존성 역전 법칙 때문입니다.
• 데이터 로직을 분리시키기 위해 Interface는 Domain Layer에, 데이터 로직 구현은 Data Layer에 작성합니다.
• Repository는 도메인과 데이터 계층의 연결고리가 되는데 구현부를 Data Layer에 작성하고 구현부로부터 독립시켜주었기 때문에 데이터 로직을 캡슐화하여 사용할 수 있게 됩니다.
• Data가 로컬 데이터인지 웹 응답에 의한 데이터인지 관계없이 동일한 인터페이스를 통해 데이터를 접근할 수 있게 됩니다.

 

 

 

View에 플랫폼 종속성을 모아두기

일반적으로 View에 플랫폼 종속성을 몰아두고 Presenter 영역에는 플랫폼 종속성을 두지 않고자 합니다. 안드로이드에서 ViewModel은 Presenter 영역에 속하기 때문에 이번 프로젝트에서는 안드로이드 플랫폼 종속성을 View로 넘기고자 했습니다.

• SingleLiveEvent를 EventFlow로 변환
• DataStore 사용을 View로 이동

 

 

 

 

주의할 점

Domain Layer와 Data Layer는 안드로이드 플랫폼에 종속되지 않도록 해야합니다. 이 계층에서는 Android 패키지를 사용하지 않도록 합니다.

주로, Paging3를 Domain 계층에서 의존성을 갖게 되는 경우가 있는데 이를 해결하기 위해서는

// 안드로이드에 대한 종속성이 없어서 sync가 가능하다.
// alternatively - without Android dependencies for tests
testImplementation "androidx.paging:paging-common:$paging_version"

위 testImplementation을 implementation하면 된다고 합니다.

 

 

참고 블로그

[Android] 요즘 핫한 Clean Architecture 왜 쓰는 거야? : NHN Cloud Meetup