서론
많이들 Clean Architecture에 대해 알고 있을 것이다. Clean Architecture 말고도 비슷한 컨셉을 가진 아키텍쳐들이 많이 공개가 되었지만 아무래도 Uncle Bob씨가 유명하기도 하고 Clean이라는 단어가 가진 영향력이 많이 컸다고 생각이 든다. 왜 이런 아키텍쳐가 나왔는지 한번 이야기해보자
Clean Architecture 컨셉
일단 Clean Architecture가 나온 배경에 대해 생각해보자면 아마 많은 서비스들이 비즈니스 규칙에 대해 관심사가 제대로 분리되지 않아서 테스트가 어려운 환경을 조성하거나 프레임워크가 바뀌거나 데이터베이스가 바뀌거나 UI가 바뀔때마다 비즈니스 규칙에 영향이 가기 때문에 이러한 비즈니스 규칙에 대한 재사용에 많이 어려움이 있었다라고 생각이 든다. 그래서 Uncle Bob씨는 비즈니스 규칙에 대한 관심사를 분리해서 관리하면서 저수준과 고수준 계층으로 나눠서 저수준에서 고수준으로 의존관계를 가지게 하면 어떨까 라는 생각을 하게 된것이다. 이때 저수준이란 가장 변경되기 쉬운것을 뜻하고 고수준이란 가장 변경이 되지 않는 것이라고 이해하면 좋을 것 같다. 이렇게 되면 의존관계가 저수준에서 고수준으로 향하게 되기때문에 프레임워크(가장 변하기 쉬운 저수준 모듈)가 없이도 독립적인 비즈니스 규칙에 대해 단위 테스트가 가능하고 UI가 변경되던 프레임워크가 변경되던 비즈니스 규칙에는 아무 영향이 없는 것이다.
출처 : http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
일단 Uncle Bob이 아까 말한 컨셉을 표현하기위해 원형 다이어그램으로 나타낸 그림이 있다.
Uncle Bob은 꼭 이 4개를 지킬필요는 없으며 이해를 돕기위해 4개로 나눠서 보여준거라고 한다. 결국 최소한 Clean Architecture에서 제시하는 컨셉대로만 지킨다면 계층이 몇개로 나뉘든 크게 상관이 없다는것같다. 그래서 경우에 맞게 계층을 나누면 될거라고 생각이든다.
일단 Uncle bob이 예시로 보여준 4가지 계층에 대해서 알아 보겠다.
Entity, Use Case, Interface Adapter, Framework Driver
일단 Entity 부터 보면 간단하게 이야기하면 전사 비즈니스 규칙이라고 하는데 이는 회사에서 전체적인 데이터를 관리하는 리소스라고 보면 될것같다. 그래서 여러가지 어플리케이션 제품에서 사용할수있는 데이터소스들이라고 보면 될것같다. 만약 회사에서 관리하는 어플리케이션이 하나라면 그 어플리케이션에 대한 비즈니스 규칙이라고 봐도 무방하다.
여기서 이야기하는 Use Case란 Entity로 부터 데이터의 흐름을 받아와서 처리하는 어플리케이션에 대한 비즈니스 규칙이다.
Interface Adpater는 UseCase에서 받아온 데이터를 프레임워크에 맞게 변경해주는 역할을 한다. 그래서 프레임워크가 변경됨에 따라 Interface Adapter도 변경되게 된다.
Framework , Driver는 데이터베이스나 웹 프레임워크 등 일반적으로 프레임워크나 도구로 구성된다.
Android에서의 Clean Architecture
Android 에서는 크게 3가지의 계층으로 나뉜다. Data Layer, Domain Layer , Presentation Layer로 나뉜다. Data Layer를 보면 Server나 DB에서 데이터를 받아오고 그 데이터에 대한 처리를 DataSource에서 한다. Repository에서는 DataSource에서 받아온 데이터를 Mapper를 통해 Domain에 대한 데이터로 변경해준다. Domain에 대한 데이터는 어플리케이션이 사용하는 실제 데이터를 뜻한다. 그래서 Domain Layer에서는 UseCase를 통해 행위에 맞게 데이터 처리를 해서 Presneter나 ViewModel에 데이터를 제공한다. 마지막으로 Presentation Layer에서는 Usecase에서 받아온 data를 view에 표시해주기 위해 Presenter나 ViewModel에서 적절히 처리를 해주게 되서 view에 표시하게 된다.
