[Android] hilt와 함께 보는 clean architecture에 대한 고찰

출처: unsplash.com

 

이번 포스팅에서는 Android 개발에서 왜 clean architecture를 사용하는지, 그리고 내가 clean architecture에 관해서 궁금했던 것들을 공부해서 적어 보고자 한다.

내가 공부하면서 참고한 포스팅도 함께 남길 테니 더한 내용이 궁금하면 확인해 보는 것도 좋겠다.

 

clean architecture의 정의

정의는 다른 포스팅에도 자주 언급되기 때문에 간단하게 설명하겠다.

clean architecture는 소프트웨어 시스템의 구조를 설계할 때 지켜야 할 원칙과 방법을 정의한 개념.
복잡한 소프트웨어 시스템을 보다 관리 가능하고 유지 보수 가능한 형태로 구축하기 위한 지침을 제공한다.

 

간단하게 요약하자면, 규모가 큰 소프트웨어를 설계할 때 지켜야 하는 구조 같은 거라고 이해하면 될 것 같다.

 

 

그래서 왜 쓰는가?

처음에 이 개념을 접했을 때는 그냥 좋구나 하고 사용했던 기억이 있다.

시간이 흐르고 나니까 왜 이 개념을 적용해야 하는지 궁금해졌다.

 

원래는 관심사를 분리해서 테스트 용이성을 높일 수 있어서 사용하는 것으로 알고 있었다.

이것도 정답이지만, 다른 이유가 더 있더라.

1. 확장성
   계층 간의 분리로 부작용 없이 시스템을 확장하거나 변경할 수 있다.
    ↳  뇌피셜이지만 이는 multi module을 이용해 feature(기능) 별로 module을 만들어서 사용하는 경우에 큰 도움이 될 것 같다.
2. 쉬운 탐색
   구분된 계층과 각 책임에 따라 네이밍 된 파일들로 이루어져 있기 때문에 특정 코드를 검색하고 이해하기 쉽다.
    ↳ clean architecture를 적용해 본 경험이 있다면 충분히 공감할 수 있을 것이다.
3. 협업 용이성
   잘 정의된 clean architecture는 팀이 앱의 각각의 기능을 동시에 작업하기가 용이하다.
    ↳ 자신이 맡은 기능을 clean architecture로 구현하면 다른 팀원의 코드를 침해하는 경우를 줄일 수 있다.

다른 장점들도 많지만 내가 가장 공감이 가는 장점들로 가져와 봤다.

추가적인 장점들이 궁금하면 아래 포스팅을 확인해 보자.

참고 포스팅 1, 참고 포스팅 2

 

 

그러면 clean architecture를 어떻게 구현해야 잘 구현했다고 말할 수 있을까?

바로 solid 원칙을 준수하면서 clean architecture를 구현하는 것이다.

 

clean architecture와 solid 원칙

clean architecture은 solid 원칙과 깊은 연관이 있다.

clean architecture를 구현하면서 solid 원칙을 준수하는 것이 중요하다.

1. 단일 책임 원칙(SRP)
   클래스는 하나의 책임을 가져야 한다. 하나의 클래스에 하나의 함수만 존재해야 한다는 것이 아닌. 클래스의 주제가 주체가 되어야 한다
   ex) 도서관을 예로 들면, 대출 및 반납을 관리하는 클래스에서는 대출, 반납 함수만, 도서 재고를 관리하는 클래스에서는 도서 추가, 삭제 함수만 있어야 한다.
    ↳ clean architecture에서는 각 계층에게 명확한 책임을 부여해야 한다. 같은 계층이어도 기능에 따라 정확히 구분해 주어야 한다.
2. 개방-폐쇄 원칙(OCP)
   확장에는 개방적이지만 수정에는 폐쇄적이어야 한다. 즉, 소스 코드를 변경하지 않고도 클래스의 동작을 확장할 수 있어야 한다. 
    ↳ clean architecture에서는 기존 구현 코드를 수정하지 않고 새로운 기능을 담은 함수를 추가해야 한다.
3. 리스코프 치환 원칙(ISP)
   상속되는 클래스가 부모 클래스의 역할을 완전히 대체할 수 있어야 한다.
   ex) 직사각형은 높이 너비를 독립적으로 변경할 수 있지만, 정사각형은 높이와 너비가 함께 변경되기 때문에 정사각형은 직사각형의 하위 타입으로 적절하지 않다.
    ↳ repository가 data source의 자식들 중 어떤 것을 사용해도 동일한 역할을 해야 한다.
   
   상속을 통해 처리하는 방법보다 멤버 변수처럼 가지고 있으면 예상하지 못한 확장이 일어났을 때도 멤버변수를 추가하거나 변경하는 형태로 다른 영향을 끼치지 않도록 할 수 있다.
    ↳ use case에서 여러 개의 repository를 property로 추가 또는 변경해서 로직을 구성할 수 있고, view model에서는 여러 개의 use case property를 사용할 수 있다.
   
4. 인터페이스 분리 원칙(ISP)
   인터페이스는 지나치게 광범위하거나 지나치게 많은 기능을 구현하면 안 되고, 그 인터페이스를 사용하는 객체를 기준으로 분리되어야 한다.
    ↳ clean architecture에서는 각 계층 간의 통신을 위해 인터페이스를 사용한다. 이 인터페이스는 각각의 목적을 가지고 다른 목적에 이용되지 않도록 구현해야 한다.
   
5. 의존성 역전 원칙(DIP)
   고수준 모듈은 저수준 모듈의 구현에 의존하면 안 된다. 대신 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존한다.
    ↳ clean architecture에서는 추상 클래스와 인터페이스를 활용해 하위 모듈의 변경이 상위 모듈에 영향을 미치지 않도록 설계해야 한다.
   

추가적인 정보는 아래 포스팅을 참고하자.

https://www.pinslog.com/146

Clean Architecture를 이해하기 위해 알아보는 SOLID 원칙

 

clean architecture의 각 계층의 구조

clean architecture의 각 계층은 data, domain, ui(presentation) layer로 이루어진다.

1. data
   앱에서 처리하는 다양한 유형의 데이터별 저장소 클래스로 구성된다.
   다른 layer는 data source에 직접 접근해서는 안된다. data layer의 진입점은 항상 repository class 이어야 한다.
   repository에서 data source를 이용한 비즈니스 로직을 구성한다.
   
   1. repository
   2. data source
2. doamin(선택사항)
   복잡한 비즈니스 로직이나 여러 view model에서 재사용되는 간단한 비즈니스 로직을 캡슐화한다.
   복잡성을 처리하거나 재사용성을 선호하는 등 필요한 경우에만 사용해야 하는 layer.
   use case에서 data layer의 repository를 불러와 캡슐화한다.
   
   1. use case  
3. ui(presentation)
   화면에 application 데이터를 표시하고 사용자 상호작용을 진행한다.
   사용자 상호작용 또는 네트워크 응답 등으로 인해 데이터가 변할 때마다 변경사항을 반영하도록 UI가 업데이트되어야 한다.
   ui state를 정의하고 view model에서 ui state를 이용해 ui element에 state 정보를 전달한다.
   
   1. ui elements
   2. view model
   3. ui state

아키텍처 구성에 대한 더 자세한 정보는 공식 문서를 참고.

https://developer.android.com/topic/architecture?hl=ko

앱 아키텍처 가이드  |  Android Developers

 

clean architecture와 hilt

이 clean architecture를 구현할 때 항상 따라다니는 것이 의존성 주입이다.

그중 hilt를 자주 사용한다.

왜 clean architecture를 구현할 때, hilt를 사용하는 걸까?

 

hilt는 아래와 같은 장점이 있다.

1. 보일러 플레이트 코드 감소
   hilt는 의존성 주입 코드 대부분을 생성해 줘서 Dagger에 비해 작성해야 할 보일러 플레이트 코드의 양을 줄여준다.
2. 안드로이드 컴포넌트와 통합
   activity, fragment, view model 등 안드로이드 컴포넌트와 원활하게 통합되어 이러한 클래스에 의존성을 쉽게 주입할 수 있다. @AndroidEntryPoint와 @HiltViewModel이 있다.
3. 모듈식 아키텍처 지원
   hilt는 milit module project 환경에서도 잘 작동한다. 이로 인해 의존성을 정의하고 필요한 곳에 주입할 수 있다.

 

이제 hilt가 위의 장점들이 있어서 clean architecture에서 의존성 주입 라이브러리로써 쓰이는 것은 알겠다.

하지만 여기서 더 궁금해진다.

clean architecture를 구현할 때, 꼭 의존성 주입이 필요한 건가?

 

공식 문서에서도 의존성 주입 라이브러리를 사용하지 않고 clean architecture를 구현한 sample을 제공하고 있다.

의존성 주입이 clean architecture에 필수적으로 진행해야 하는 작업이 아닌 건 알겠는데 그러면 안 해도 되는 거 아닌가?

 

위 같은 생각이 들어서 자료를 더 찾아보게 되었다. 

 

꼭 의존성 주입을 해야 하는 걸까?

아무리 찾아봐도 자료들이 나오지 않아서 AI(perplexity) 기반 뇌피셜을 정리해 보겠다.

 

clean architecture의 장점으로 대부분이 이렇게 언급한다.

• 관심사의 분리
• 테스트 용이성

clean architecture에서의 핵심은 의존성 규칙이다. 의존성 규칙에 따르면 내부 layer는 외부 layer에 의존하면 안 된다.

의존성 주입을 사용하지 않고도 이 규칙을 따를 수는 있지만, 의존성 주입을 사용하면 이 규칙을 더 쉽게 준수할 수 있다.

의존성 주입 라이브러리인 hilt를 사용하면 의존성 관리가 더 간편해지고 수동으로 의존성을 주입할 수도 있다.

 

정리

이번에 다양한 clean architecture에 대한 자료들을 찾아보면서 clean architecture에는 solid 원칙, 의존성 주입과 hilt 등 다양한 개념들이 연관되어 있다는 것을 알게 되었다.

다양한 개념을 찾아보면서 공부하는 계기가 되었다.

 

궁금했던 것들은 자료들이 많지 않아서 AI(perplexity) 기반의 뇌피셜을 기반으로 작성한 점 양해 부탁한다.

혹시 누락된 점과 추가할 개념이 있다면 제보해 주면 고맙겠다.

 

다음에는 clean architecture와 함께 준 필수적으로 사용되는 디자인 패턴인 mvvm에 대한 고찰을 진행해 보겠다.

사실 말만 고찰이지 그냥 내가 궁금했던 내용들을 정리하는 포스팅이다.