[Android] 클린아키텍처에 대해서 살짝 맛보기

클린아키텍처에 대해 많은 관심을 갖고 다양한 회사에서 도입 및 시도하고 있습니다.
어떻게 구성해야 클린 아키텍처일까요?
 
이상적인 아키텍처에 대해서 로버트 C. 마틴에 의해서 소개 되었으며 복잡한 소프트웨어 시스템을 보다 관리 가능하고 유지보수 가능한 형태로 구축하기 위한 지침을 제공하였습니다.
로버트 C.마틴이 말한 클린 아키텍처의 기본적인 개념과 어떻게 Android 환경에서 도입하였는지에 대해서 Medium 에 글이 등재 했는데요. 등재한 글의 일부를 공유하겠습니다. 
 
자세한 내용은 왜 Android 신규 프로젝트는 클린 아키텍처를 도입하였는가? 라는 기술블로그 에서 확인 할 수 있습니다.
 
 

클린 아키텍처를 왜 쓰는걸까?

http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

 
클린 아키텍처는 소프트웨어 시스템의 구조를 체계적으로 설계함으로써 여러 가지 장점을 제공하는데요.
가장 중요한 장점 중 하나는 시스템의 각 부분을 독립적으로 개발하고 테스트할 수 있는 환경을 조성할 수 있다는 점입니다. 또한 시스템의 변경이나 업그레이드가 필요할 때 전체 시스템을 다시 작성하지 않아도 되며, 특정 부분만 수정하는 것이 가능해집니다.
 
현업에서 일한다면 개발 후 운영의 앱 중 특정 부분의 수정을 요청하는 경우를 경험했을 것입니다.
A 회사는 Network 통신 라이브러리인 Retrofit의 Convert Factory를 Moshi Factory로 사용하고 있었습니다.
어느날 Moshi Facory가 아닌 Gson Convert Factory 으로 전면 변경하라는 기술 지침이 내려온다면 개발자는 프로젝트 안에서 Network 통신 하는 곳을 모두 찾아서 Moshi Factory 를 Gson Convert Factory 라이브러리로 변경하는 귀찮음과 코드를 찾는 수고가 발생할 수 있습니다.
또한 모든 부분을 변경하였다고 생각하였으나, 일부 코드의 미수정으로 인한 사이드이팩이 발생할 수도 있습니다.
 
이와 동일한 조건으로 Network 방식을 변경한다면 클린아키텍처로 구성된 코드에서는 Network 통신을 담당하는 Layer 만 확인 후 Network 통신 라이브러리를 변경작업하면 됩니다. 이렇게 한곳에서만 수정하면 모든 코드를 찾으면 하나씩 변경하는 수고는 적게되고 그만큼 사이드이팩에 대한 두려움도 줄어들 것입니다.
 
 

클린아키텍처 Android 환경 구성 어떻게 해야할까?

클린 아키텍처를 Android 의 구조에 맞춰서 개발하는 가이드라인은 Google Developer Document(Guilde to app architecture) 에 명시되어 있어 참고해서 개발할 수 있습니다. Google Developer Document 을 참고하기에 어렵다면 참고할 만한 다수의 블로그가 존재하기에 그것을 참고해서 작성하셔도 됩니다.
 
여기서 중요한 것은 각 계층인 Layer 를 분리해야합니다. 예를들어서 Presentation Layer, Domain Layer, Data Layer는 하나의 모듈에서 존재하는 것보다 각각 Module 구성을 하여 의존성을 낮추는게 중요합니다. 
 
왜 Android 신규 프로젝트는 클린 아키텍처를 도입하였는가? 에 명시되어 있는 Flow 를 참고하시면 Presentation, Domain, Data Layer는 분리되어 있고, Domain은 어느 모듈도 의존하고 있지 않도록 구성되어 있습니다.
 

https://medium.com/cj-onstyle/android-%EB%B2%84%ED%8B%B0%EC%BB%AC-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EC%9D%98-%ED%81%B4%EB%A6%B0-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EB%8F%84%EC%9E%85-a26d833e103c

 
 
클린아키텍처를 도입할 프로젝트의 개발 환경 및 비즈니스 로직의 구성에 따라서 Domain Layer 부분이 생략 될 수 도 있습니다. 
Google 에서도 Domain 은 optional 하게 가이드하고 있어서 상황에 맞게 구성할 것을 추천드립니다.
 

Mapper 는 왜 존재할까?

Mapper는 API 에서 내려준 DTO(Data Transfer Object)를 UI에 적합한 Entity로 변경하는 기능을 담당하고 있습니다. 이 말은 클린아키텍처 구조에서 설명하자면, Data Layer에서 API 로 전달받은 DTO 를 Domain Layer 에서 UI 에서 사용하기 좋은 형태인 Entity로 변경한다고 보시면됩니다.  다시말해 UI 에서 사용할 데이터는 API에서 내려준 Data와 동일할 필요가 없으며, UI에 최적하게 재배치를 할 수 있는 환경을 Mapper가 제공한다고 이해하시면 됩니다. 
 
Mapper 의 또 다른 존재 이유는 디버깅 환경 구성입니다.
API 가 개발 안된 상태에서 기능 개발은 어려움이 있어 대부분의 회사에서는 API 가 개발되기 전에 Mock 데이터를 제공하고 있습니다.
Mock 데이터 구성을 Mapper를 통해서 UI에 맞춰서 구성한다면, UI와 비즈니스로직 그리고 Mock 데이터 간의 코드 분리 및 의존성을 낮춰 추후 API 개발 완료 시 Mock 데이터에서 API 데이터로 연결만 변경하여 쉽게 Data 전환이 가능합니다.
 
 

마무리

클린아키텍처에 대해서 간단히 알아보고 어떻게 Android 에서 클린아키텍처를 구성에 대해서 간략히 가이드하였습니다. 
아키텍처를 왜 사용하는지에 대해서 의문을 갖고 있는 분들이 있을 것입니다. 
 
필자가 생각하기에는 아키텍처는 협업의 소통 도구라고 생각됩니다. 코드로 소통하는 개발자는 보통 사람과의 대화보다 명확히 의사 전달을 하고 있습니다. 따라서 인수인계를 위해서 몇 시간 회의실에서 인수인계를 진행하는 것보다 아키텍처를 소개하고 아키텍처의 구조에 맞춰 개발할 것을 가이드한다면, 코드의 통일성 및 가독성이 올라갈 것입니다.  이점을 참고해서 클린아키텍처를 도입하는 것을 고려해도 좋을거 같습니다.
 
클린아키텍처의 대한 자세한 내용은 Medium(왜 Android 신규 프로젝트는 클린 아키텍처를 도입하였는가? ) 에서 확인할 수 있으며, 본 기술블로그에 등재된 '같이보면 좋은글'의 클린아키텍처 관련 글을 읽는 것도 추천드립니다.