Clean Architecture [1]
시스템 구조에 관한 여러가지 아이디어들이 존재하며 각각은 세부적으로는 다르나 관심사 분리라는 공통된 목적이 존재하며 각각의 layer는 아래와 같습니다.
Layers
-
Entities
전반적인 business rule을 가지고 있는 layer로 해당 business에 대한 다양한 application들에서 재사용 될 수 있는 layer입니다. -
Use Cases
Application specific한 business rule을 가지고 있는 layer입니다. -
Interface Adapters
Use case와 entity에서 받은 data를 외부 framework 등에서 사용하기 좋게 가공하는 layer입니다. Presenter, View, Controller 등이 여기에 속합니다. Model 클래스는 보통 use case와 주고 받는 data structure입니다. -
Frameworks and Drivers
Application을 만들때 사용하는 framework, database 등이 포함되어 있는 layer입니다.
Clean Architecture의 이점
Clean architecture를 지키면 얻을 수 있는 이점은 다음과 같습니다.
-
Framework에 독립적이다.
Architecture가 library의 기능에 종속적이지 않습니다. -
UI에 독립적이다.
시스템을 변경하지 않고 UI를 쉽게 변경할 수 있습니다. -
Database에 독립적이다.
Business rule이 database에 종속적이지 않아 database를 쉽게 변경할 수 있습니다. -
외부 agency에 독립적이다.
Business rule이 외부 상황에 아무런 관계가 없어야 합니다. -
테스트가 가능하다.
위와 같은 특징 덕분에 UI, database, 외부 요소 없이 테스트가 가능합니다. -
코드 재사용성이 좋아진다.
외부적인 요소로 부터 독립적이므로 코드 재사용성이 좋아집니다.
위와 같은 이점이 생기는 이유는 clean architecture에서 중요한 법칙인 dependency rule 때문입니다.
Dependency Rule
위의 clean architecture의 그림에서 바깥쪽 원은 하위 layer, 안쪽 원은 상위 layer입니다. Dependency rule은 dependency는 바깥에서 안쪽으로만 향하도록 하는 법칙입니다.
즉, 상위 layer가 하위 layer로의 dependency를 가지지 않아서 framework, UI 등으로 부터 독립적이게 되므로 business rule이 있는 entity layer와 use case layer를 재사용하기 용이하게 됩니다.
하지만 API나 database에서 데이터를 가져와야 하는 등의 상황에서는 상위 layer에서 하위 layer로 dependency를 가져야할 경우가 생기게 됩니다. 이럴 경우에는 dependency inversion principle을 이용하여 dependency의 결합을 낮추어야 합니다.
Android Recommanded App Architecture [2]
Android developers에서 추천하는 application architecture는 3가지 layer로 나뉘어있습니다.
Layers
-
UI
UI layer는 이름에서 알 수 있듯이 UI를 담당하며 UI 요소들과 UI의 상태를 나타내는 state holder가 존재합니다.
UI 요소는 Activity, Fragment 등의 View이거나 Jetpack Compose function이며 state holder는 View의 state를 저장하고 있는 클래스로 보통 ViewModel에 LiveData 혹은 Flow를 이용하여 state를 가지게 됩니다. -
Data
Data layer는 business logic을 담고 있고 repository와 data source가 존재합니다.
Data source는 application에서 필요한 data를 가져올 API 혹은 local database 등에 대한 interface입니다. Repository는 여러개의 data source를 가지며 data source들의 conflict를 해결하고 data를 반환하여 application에서 사용할 수 있도록 합니다. -
Domain
Optinal한 layer로 UI layer와 Data layer사이에 위치하며 복잡한 business logic과 자주 재사용되는 use case들이 있습니다.
비교
UI layer와 Interface Adapters, Frameworks and Drivers layer
UI layer는 UI 요소인 View와 state holder인 ViewModel 등이 존재합니다. View는 frameworks and drivers layer에 속하고 state holder는 interface adapters layer에 속합니다. 단, AAC의 ViewModel의 경우 Android framework에서 제공하는 클래스로 frameworks and drivers layer에 속합니다.
Domain layer와 Entity, Use Case layer
Domain layer는 복잡한 business logic과 자주 재사용되는 use case들이 존재한다고 하였습니다. Clean architecture에서 entity layer와 use case layer는 각각 자주 재사용되는 business rule과 use case를 가지고 있습니다.
Data layer와 Frameworks and Drivers layer
Data layer는 application에 필요한 API 혹은 database들이 포함되어 있습니다. 이는 clean architecture에서 frameworks and drivers layer에 속합니다.
Android recommanded app architecture 그림에서 domain layer가 data layer에 접근하는 것을 볼 수 있습니다. 이는 clean architecture에서 dependency rule을 어기게 되므로 repository의 interface를 추가하여 DIP로 dependency의 방향을 바꾸어주어야 합니다.
Reference
[1] "The Clean Architecture," The Clean Code Blog, last modified n.d., accessed Feb 10, 2022, https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html.
[2] "Guide to app architecture," Android Developers, last modified Aug 01, 2022, accessed Aug 17, 2022, https://developer.android.com/topic/architecture.
