[안드로이드] - 클린아키텍처 - 3

이전 편 2탄에서는 밥아저씨가 소개한 클린 아키텍처를 설명하였다.

이번에는 안드로이드 개발자는 어떤식으로 클린 아키텍처를 적용할 것인가? 에 대해서 블로그를 적어보려 한다.

 

모바일 클린 아키텍처

모바일 환경 자체의 특성에서 오는 문제가 있다.

자원의 한계, 라이프 사이클를 신경써야하는 부분 등 많은 문제가 있으나 가장 큰 문제가 되는 부분은 프리젠테이션 로직 복잡도다.

 

모바일 앱의 경우 뷰 상태가 매우 복잡하고, 비동기 처리가 많은 특성이 있다.

비동기 처리 없이 순차적인 시간 흐름으로 뷰 로직을 처리하는 것은 불가능한 경우가 많기 때문에 심플하게 코드 짜는 것이 쉽지 않다.

어느 순간 내가 짠 코드조차도 특정 이벤트에 대한 반응 로직이 어찌되어 있는지 코드를 보고 바로 이해하기가 힘든 경우가 흔히 생긴다.

 

이런 문제들로 인해 Acitivity, Fragment 쪽 코드가 비대해진다. 비대해진다면 위에서 언급한대로 코드를 다시 보고 이해하는데 시간이 걸린다느 말이다. 개발자는 효율을 생각해야 하는데 직업으로써 굉장히 모순적인 행동을 하고 있는 것이다.

 

그래서 아키텍처를 도입하는 것이다.

 

아래 그림은 밥 아저씨가 제공한 클린아키텍처를 모바일 클린아키텍처 구조로 변경한 다이어그램이다.

클린아키텍처 -> 모바일 클린아키텍처 재구성

 

밥아저씨 클린 아키텍처에는 네 개의 계층이 존재한다.

하지만, 모바일 클린 아키텍처는 세 개의 계층으로 나뉜다.

세 계층으로 뉘는 Clean Architecture

 

프레젠테이션 계층

이는 화면의 표시, 애니메이션, 사용자 입력 처리 등 UI 에 관련된 모든 처리를 갖고 있다.

또한 Domain 계층과 Data 계층에 의존성을 갖는다.

• 뷰(View) : 안드로이드 플랫폼에 의존적인 구현. UI 화면 표시와 사용자 입력만 담당한다.
• 프레젠터(Presenter) : MVP 에 Presenter, MVVM 에 ViewModel 과 동일한 의미로 생각할 수 있다. 프레젠터는 뷰와 달리 플랫폼에 직접적으로 의존하지 않는 클래스이다. 따라서, 손쉽게 단위 테스트가 가능하다. 또한, 뷰와는 달리 화면에 그리는 것이 어떤 의미를 가지고 있는가를 알고 있습니다. 즉, 사용자 입력이 왔을 때 어떤 반응을 해야하는 지에 대한 판단도 역시 프레젠터가 한다.

 

도메인 계층

비즈니스 로직을 처리하는 계층이다. 

• 유스케이스(UseCase) : 도메인 계층에서 굉장히 중요하다. 각 개별 기능 또는 비즈니스 논리 단위라고 생각하면 된다.
• 엔티티(Entity) : 앱의 실질적인 데이터이다.
• 트랜스레이터(Translater) : 데이터 계층의 모델 - 도메인 엔테티를 변환하는 mapper 의 역할

 

데이터 계층

DB, Server 와 상호작용하는 계층이다.

• 리포지터리(Repository) : 유스케이스가 필요로 하는 데이터의 CRUD(저장 및 수정 등)의 기능을 제공하는 영역으로, 데이터 소스를 인터페이스로 참조하여, 로컬 DB와 네트워크 통신을 자유롭게할 수 있다.
• 데이터소스(DataSource) : 실제 데이터의 입출력이 여기서 실행된다.
• 데이터모델(Model)
• Mapper

---

모바일 클린 아키텍처 데이터 흐름

1. 사용자에게 Click 이벤트 발생

2. 이벤트에 해당한 데이터를 서버쪽으로 이동

3. 서버가 응답 후, 다시 클라이언트로 데이터 전달

4. 서버에서 전달 받은 모델을 클라이언트에 맞는 모델로 mapper 를 통해 변경

5. 프레젠테이션 계층으로 이동하여, Entity -> UIModel 로 데이터 변환

6. 해당 UI 를 갱신함.

---

여러가지 의문점

도메인 계층 entity 와 데이터 계층 model 은 무슨 차이일까?

데이터 계층의 엔티티는 클린아키텍처 다이어그램에 나와있는 엔티티가 아니다.

데이터 계층의 엔티티는 네트워크나 로컬DB 에서 받아온 DTO를 의미한다.

 

따라서 계층을 횡단할 때 해당 계층에 맞게 변환해야 한다.

도메인 계층에서 엔티티가 Translater 과정을 거쳐 데이터 계층의 모델로 변환되는 것이고, 이와 반대로도 가능하다.

 

이렇게 계층화하면 무엇이 좋은걸까?

가장 큰 이점은 사이즈가 큰 앱이더라도 소스코드 전반을 쉽게 장악할 수 있다.

복잡한 수정사항이 생겼을 때라도, 어떤 분분을 고치면 되는지 금방 파악할 수 있다.

 

솔직히 구조화되서 좋은 이점도 많다. 이를 다 구현해야하는 걸까?

장점이 많지만, 굉장히 복잡한 구조이다. 간단한 로직을 구현할 때에도 상당히 많은 양의 클래스를 생성해야 한다.

이 경우 몇 가지 해결책이 존재한다.

• 요소들을 통합하기 ex. 데이터 계층에서 데이터소스와 레포지토리 통합
• 필요없는 요소 축약하기 ex. 유스케이스 생략(일부는 레포지토리와 프리젠터로 흡수 시킨다)
• 도메인과 데이터를 통합하기 ex. 두 계층을 통합하여 고수준의 리포지토리 클래스 구현

 

정리

모바일 클린아키텍처와 밥아저씨가 말한 클린아키텍처는 확실히 다르다.

 

참고

https://meetup.nhncloud.com/posts/345
https://youngest-programming.tistory.com/484
https://velog.io/@galaxy/Clean-Architecture
https://heegs.tistory.com/57
https://joonfluence.tistory.com/322
https://medium.com/@justfaceit/clean-architecture%EB%8A%94-%EB%AA%A8%EB%B0%94%EC%9D%BC-%EA%B0%9C%EB%B0%9C%EC%9D%84-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8F%84%EC%99%80%EC%A3%BC%EB%8A%94%EA%B0%80-1-%EA%B2%BD%EA%B3%84%EC%84%A0-%EA%B3%84%EC%B8%B5%EC%9D%84-%EC%A0%95%EC%9D%98%ED%95%B4%EC%A4%80%EB%8B%A4-b77496744616
https://zeddios.tistory.com/1065
https://github.com/kudoleh/iOS-Clean-Architecture-MVVM
https://if.kakao.com/2022/session/85