clean Architecture 정리

용어 정리 

• UseCase
  : 유스 케이스(Use case)는 UML(통합 모델링 언어)의 행위자(액터)와 액터가 요구하여 시스템이 수행하는 일의 목표이다.

• Domain
  : 인터넷 주소,  (지식·활동의) 영역; (책임의) 범위

  Domain Logic: Business Logic Area로 이해하면 될 것 같다.

• Entity
  : 독립체 / DataBase 테이블의 논리적 구조

  Clean Architecture에서의 Entity는 Api에서 받은 원시 그대로의 데이터 객체 (DTO)로 보면 된다.

---

당연히 MVVM을 처음 접하시는 분은 이해가 안가실 겁니다. 

저는 처음엔 MVC 패턴과 ViewModel 만을 사용한 MVVM 패턴을 비교해보기 위해 개인 프로젝트를 시작했었습니다. 

국가 정보를 가져와서 리스트뷰에 뿌려주는 앱을 만들어 보았습니다. 
(코드 링크: https://github.com/boogil/android_mvvm_study)

MVC 패턴

단순한 MVVM 모델 적용

 

MVVM + Dependency Injection 적용

 

먼저 왜 MVVM을 적용하는가? 에 대한 의문으로 구조 파악에 들어갔습니다. 

확연하게 비지니스 로직과 Activity의 분리가 가능해서, UnitTest 시에 ViewModel 만을 가지고 테스트를 해볼 수 있겠구나! 라는 이점을 얻을 수 있었습니다. 

---

하지만, Android Clean Architecture의 구조는 더욱 세분화를 해 놓는 구조여서, 처음에는 이해도 안가고 어설프게 적용을 해봤을 때, 클래스 파일들이 엄청 많아지니까 디버깅이 안되고 왜 이게 Clean Architecture 라고 하는지 납득이 안갔습니다. 

그래서 Clean Architecture 예제 프로젝트를 정밀하게 분석해서 비교해는 작업을 해보기로 했습니다. 

 

---

Clean Architecture With Kotlin으로 공부하기 위해 아래의 소스 코드를 분석해 보았습니다.

https://github.com/android10/Android-CleanArchitecture-Kotlin

android10/Android-CleanArchitecture-Kotlin

 

Clean Architecture 구조도 

추상적인 구조도 입니다. 

제가 이해한 바로 설명해드리겠습니다. 

1. UI (Views) + Data Sources (Network, DB) 
   : Android FrameWork에 종속되는 UI, Network, DB 처리의 영역입니다. 

2. ViewModels
   : UI와 비지니스 로직을 연결시켜주는 중간 다리 역할의 영역입니다. 
     (UI 영역이라 함은 Activity, Fragment 등이 될 수 있겠네요.)

3. Use Cases
   : 하고자 하는 행위의 영역입니다.  
     (국가 정보 가져오기, 영화 정보 가져오기, 영화 틀기 등의 각각의 행위라 할 수 있습니다.)

4. Entities
   : 사용하고자 하는 데이터 구조 영역 입니다.  
     (이 부분이 사실 애매하고 이해가 잘 안됩니다.)

Android 3 Layers Architecture

3단계로 구분한 구조도 입니다. 

실제 코드를 분석하다보니, 이 구조도가 가장 이해가 잘 가는 구조입니다. 

1. Presentation Layer
   : Fragment, Activity, ViewModels, LiveData 등의 Android FrameWork와 붙어있는 영역입니다. 

2. Domain Layer
   : UseCases (행위), Repository(api, database 통신 행위), Entities(내부적 데이터 객체) 의 영역으로, 한마디로 비지니스 로직의 영역입니다. 
   

3. Data Layer
   : 정제된 데이터 객체 영역 입니다. 

위의 샘플 프로젝트를 분석해서 UML을 작성해보았습니다. 

Presentation Layer, Domain Layer, Data Layer 3개의 구조로 분리할 수 있었습니다. 

 

---

그렇다면, 첫번째 예제 프로젝트와 비교한다면 UseCase와 Entity의 개념이 더 들어간 것을 확인할 수 있습니다. 

이전 예제에선 ViewModel이 행위의 코드도 수행하고 있었습니다.

행위 자체를 분리하는것이 어떤 장단점이 있을까 정리해보았습니다. 

 

• 장점

  1. 하고자 하는 행위를 모듈화 하기 때문에 세세한 테스팅이 가능하다. 

  2. ViewModel은 Repository, Entity와의 관계를 끊을 수 있다.

  3. 비지니스 로직 코드 작성에 집중할 수가 있다. 

• 단점

  1. 코드 분석에 상당한 시간이 소요된다. (학습량이 어마어마함)

  2. 클래스 파일 수가 엄청 증가한다. (한눈에 디버깅이 안된다.)  

 

파트를 세세하게 분리하기 때문에, 다수의 개발자가 협업하기에는 CleanArchitecture가 아주 유용할 거라 생각이 들었습니다.

안드로이드도 FrontEnd, BackEnd 로 구분해서 협업을 진행할 수 있겠다는 생각도 들었고, Git 충돌도 상당히 줄어들 것으로 예상이 되었습니다.

---

Clean Architecture의 장점을 이해하게 되었고, 현 구조 기반으로 사이드 프로젝트를 만들어서 새로운 블로그로 공유하도록 하겠습니다. 

 

---

<참고자료> 

https://fernandocejas.com/2018/05/07/architecting-android-reloaded/
https://github.com/android10/Android-CleanArchitecture-Kotlin