앱 아키텍처 가이드 공식문서 다음 공식문서를 기반으로, 내용을 정리해보겠다.
소프트웨어 아키텍처는 변경하는 데에 드는 비용과 관련된 개념.
잘 만들어놓은 프로젝트를 수정할 때, 기존의 코드를 변경해서 새로 추가된 요구사항들을 개발해낼 수 있다면 굉장히 높은 생산성을 가진 팀이 될 것이다.
이처럼 아키텍처는 프로젝트를 잘 관리하기 위해서 어떻게 구조화할 것인지 기준을 설계하는 일이다.
"좋은 아키텍처는 프로젝트에 새로운 요구사항이 추가되거나 수정되었을 때, 쉽게 코드를 변경할 수 있다."
Android App은 Activity
, Fragment
, Content Provider
, BroadCast Receiver
를 비롯하여 여러 앱 구성요소들로 이루어져있다.
개발자들은 이러한 앱 구성요소들을 Manifest
에서 설정한다.
그리고 일반적으로, 휴대기기는 리소스가 제한되어있으므로. 하나의 기기환경에서 여러 App을 실행할 수 있도록 App을 개발해야 한다.
즉, 하나의 App이 너무 많은 자원을 소모한다면 제거대상 목록에도 오를 수 있고, 사용자의 측면을 전혀 고려하지 않은 것이다.
관심사를 분리하는 것은 안드로이드 App개발 뿐만 아니라, 소프트웨어 아키텍처 개발 측면에서 많이 사용되는 용어이다.
예를 들면, 안드로이드 App에서 화면을 그리는 일은 Activity
와 Fragment
가 주로 수행하게 된다.
하지만, Activity
또는 Fragment
내에서
AssetLoader
에게 데이터를 요청Adapter
에 전달.Adapter
클래스에게 뷰에 데이터를 담는 작업(binding)이 모든 작업들을 처리하는 것이 아닌, 관심사에 따라 분리하여 다른 객체가 이 책임을 나누는 형태로 수정하는 것이다.
또 하나의 중요한 것은, 데이터 모델에서 UI를 도출해야 한다는 것이다. (지속적인 모델 권장)
데이터 모델은 앱의 데이터를 의미한다.
지속 모델을 권장하는 이유
- Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않습니다.
- 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동합니다.
권장하는 바로는 UI Layer
와 Data Layer
를 나누는 것이 좋다고 한다.
Repository
에서 Data Source
에
데이터 소스는 여러가지 존재할 수 있다.
Domain Layer
는 복잡한 비즈니스 로직이나 자주 재사용되는 로직들의 캡슐화를 담당한다.
여러 ViewModel에서 재사용되는 로직이 있다면, 이를 클래스로 분리하고, ViewModel에서 클래스를 참조하는 형태로 사용.
복잡성을 처리하거나 재사용성을 선호하는 경우에는 Domain Layer
도 선택적으로 사용하는 것도 좋을 것이다.