일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 특가게시판
- Quickly
- RX
- 안드로이드
- onViewCreated
- 카드내역 공유
- 올인원타이머
- compileKotlin FAILED
- 뷰 상태 저장
- 작성
- recyclerview
- 카드 내역 공유 앱
- 뷰 상태복구
- 안드로이드 클린 아키텍쳐
- 타이머앱
- 특가촌
- todofication
- RxJava
- List
- java.lang.OutOfMemoryError: Java heap space
- andorid
- kotlin
- 대학톡
- nvidia-docker
- Android
- fragment
- android clean architecture
- Koin
- moveToState
- 특가알람
- Today
- Total
seoft
[deprecated] 안드로이드 클린아키텍쳐 데모앱 제작기 본문
[deprecated]
클린아키틱쳐에 대해 일부 생각이 바뀌어 추후 새로작성 예정, repository 도 내리고, 히스토리 관리차원에서 블로그 내용은 유지
[개요]
클린 아키텍쳐에 대한 숙지를 위해 작은 데모앱을 구성, 구성과정을 기록합니다.
Github : deprecated(github.com/seoft/seoft-android-clean-architecture)
데모앱의 간단한 요구사항은 다음과 같습니다.
- ID 와 페스워드를 서버에 검증받은 후 다음 페이지로 진입 - 연락처 데이터를 가져와 리스팅 (페이징 가능, 리플래시 가능) - 서버 요청으로 연락처 데이터 상세 조회 (사실 연락처 데이터를 다 가지고 있어서 서버요청 안해도되는데.. id로 쿼리하는 막연한 예시로..) - 연락처 데이터를 추가 혹은 삭제 - 연락처 데이터의 즐겨찾기 기능(로컬 DB연동 예시를 위한..) |
또한 프로젝트도 두가지로 구성되있습니다.
seoft/seoft-android-clean-architecture/android-clean-architecture seoft/seoft-android-clean-architecture/example-server-for-clean-architecture |
android-clean-architecture는 위의 요구사항을 만족시는 클린아키텍쳐로 구성된 안드로이드 프로젝트이며
example-server-for-clean-architecture는 안드로이드 데모앱이 연동되는 api 서버이며 api들은 다음과 같이 구성되있습니다.
[클린아키텍쳐 구성]
위의 요구사항을 클린아키텍쳐로 구성해보았습니다.
클린아키택쳐 관련해서 많이 보던 다음 이미지가 있었고 추가적으로 다른 블로그에서 봤었던 이미지인데 비교적 이해가 쉽게 구성된 것 같아 공유드립니다. (youngest-programming.tistory.com/484)
위의 이미지에서 구현한 데모앱의 구성은 다음처럼 매칭되있습니다.
위의 이미지에 대한 설명을 좀 더 상세히 풀어 말씀드리겠습니다.
A. 프레젠터 계층
UI를 출력하여 사용자에게 제공하며, 입력를 받아 전처리 후 도메인 계층으로 넘기는 역할을 합니다. 추후에 다시 도메인 계층에게 결과값을 받아와 뷰모델단에서 처리 후 UI 업데이트 진행됩니다.
엑티비티, 프래그먼트와 같은 뷰 부분을 포함하며 와 뷰와 관련된 데이터를 보유하고 도메인계층인 유즈케이스와 연결되있는 뷰모델이나 프레젠터(MVP에서의)도 포함되며, 해당 데모앱에서는 DI도 프래잰터 계층에 속하고 있습니다.
B. 도메인 계층
앱에서 행해지는 비지니스 로직을 UseCase라는 구성으로 제공하며 비지니스 로직을 위한 Repository의 내부 실 구현은 데이터계층으로 위임하고, 비지니스 로직이 구현된 UseCase 자체는 프레젠터에 전달됩니다.
프레젠터의 각 뷰모델에 필요한 UseCase만 주입하면 되므로 유즈케이스 없이 구현하는 경우와 비교했을때 의존성이 낮습니다. 유즈케이스에 필요한 순수 엔터티 클래스들도 포함되있고 다른 계층을 의존하지 않는 독립적인 계층입니다.
C. 데이터 계층
실제 서버나 DB와 연동되어 값을 보내거나 가져오는 역할을 진행, 서버와 DB의 DataSource를 담당하며 레포지토리를 통해 더 의미있게 가공되어 제공됩니다.
서버와 DB 모델에 의존적이기 때문에 유즈케이스에서의 엔터티로 변환하는 Mapper 파일도 포함하고있습니다.
[코드설명]
각 부분의 코드를 간략하게 설명드리겠습니다.
A. 도메인계층은 다음 세가지로 구성되있습니다.
- Entity 모델 - UseCase 클래스의 상위클래스인 SUseCase 외 2가지 - 실 UseCase 구현체 |
- UseCase 클래스의 상위클래스인 SUseCase 외 2가지
UseCase의 베이스 코드로 주입받은 RxScheduler에 따라 Rx의 반환타입으로 반환하는 함수 구현을 강제하는 상위클래스이며 Rx의 Single, Completable, Flowable 속성에 따라 SUseCase, CUseCase, FUseCase 세가지로 구성되있습니다.
- Entity 모델
유즈케이스의 Input과 Output으로 사용되는 kotlin 순수 클래스입니다.
해당 데모 앱에서는 프래젠터에도 도메인계층의 Entity를 사용합니다. (필요시 확장함수를 통해 프래잰터 계층에서 필요 함수 추가 후 사용)
- 실 UseCase 구현체
SUseCase외 두가지의 베이스코드를 상위로 가지고있는 실제 UseCase 클래스들, 뷰모델에 주입되고 사용됩니다.
B. 데이터계층은 크게 다음 세가지로 구성해볼 수 있습니다.
- datasource (with db,api) - Api,Db 모델, mapper - Repository |
- Api,Db 모델, mapper
api에 리퀘스트를 요청하고 리스폰스를 받기 위한 모델과 Room 을 이용하기 위한 DB모델이 존재하며
Repository에서 UseCase의 Entity로 반환을 위해 각 모델에 맞는 Mapper 클래스도 존재합니다.
- Datasource (with db,api)
Api,Db모델을 이용해 서버요청 혹은 로컬 데이터요청이 이뤄지고 순수하게 서버요청이나 db에대한 결과값을 반한한다.
- Repository
datasource들에서 받아온 데이터를 필요에 맞게 가공 한 후 mapper를 통해 유즈케이스의 엔터티에 맞는 데이터로 반환합니다다.
또한 한가지 예로 서버데이터를 db에캐싱하는 등의 케이스로 레포지토리 내부적으로 사용되는 경우도 있습니다.
C. 프래잰터계층은 다음으로 구성되있습니다.
- 뷰,뷰모델을 위한 유틸성 클래스들 - 프레젠터계층용 data - di 구성요소 - 뷰, 뷰모델 |
- 뷰,뷰모델을 위한 유틸성 클래스들
뷰와 뷰모델에서 사용되는 유틸성클래스, 바인딩어뎁터, 베이스클래스 등을 포함하고있습니다.
- 프레젠터계층용 data
github에 안드로이드 클린아키텍쳐 관련 코드를 보면 프레젠터전용 Data클래스를 가져가져 mapper를 따로 두는 경우도 있는데,
해당 데모앱은 단순 1:1 맵핑을 위해 딜리버리만 하도록 구성되어 프래젠터계층이지만 도메인계층의 Entity를 사용하며 도메인 계층의 data class의 확장이 필요한 경우 관련 확장함수를 프래잰터내에 구성하고있습니다.
- 뷰, 뷰모델
UI의 구성요소인 뷰와 뷰의 데이터를 관리하는 뷰모델이 구성되있으며 뷰모델에는 뷰의 역할에 맞는 UseCase가 주입되어 사용됩니다.
- di 구성요소
앞서 살펴본 데이터, 도메인, 프레젠터 각 계층의 연결을 조합하여 앱을 구동시키는 역할을 합니다.
[기타사항]
실제로 github 에 android clean architecture 를 검색해보면 많은 안드로이드 클린아키텍쳐 프로젝트들을 볼 수 있습니다. 하지만 각 코드마다 구성된 라이브러리가 다르고 또한 계층에 대한 구성도 조금씩다릅니다.
구성이 다른 경우를 찾아봤을때는 다음과 같습니다.
- data계층에 gateway 모듈을 따로두어 세분화하는 경우 - 각 계층의 구현체를 추상화 하는 경우 혹은 안하는 경우 - 대부분의 프로젝트가 usecase의 코틀린 파일 하나가 유일하게 한가지의 단위로 구성됬는가 하면, 몇몇 프로젝트는 여러가지의 단위로 구성되는 경우 |
이처럼 구현방식이 기술스택으로 부터 차이가 나면서 구현이 달라지고, 클린아키텍쳐의 계층에 대한 정의를 받아들이는사람들도 각각 달라 정확히 이거다!! 할 수 있는 코드는 없는 것 같습니다. 물론 제가 구현한 코드도 클린아키텍쳐에 대한 다양한 블로그와 코드를 참고하여 제가 생각할때 필요가 떨어지는 부분은 제외시키고 필요한부분은 덧붙이며 개발을 진행하였으니 참고부탁드립니다.
감사합니다.
[참고사항]
youngest-programming.tistory.com/484
github.com/woowabros.github.io/experience/2019/01/17/baeminapp-clean-architecture.html
ichi.pro/ko/android-ui-keullin-akitegcheo-choboja-jeobgeun-bangsig-208962507866219
medium.com/swlh/clean-architecture-in-android-a-beginner-approach-be0ce00d806b
github.com/ngallazzi/cleanarchitectureblueprints
'android' 카테고리의 다른 글
DiffUtil 아이템 개수와 데이터 교체 방법에 따른 종합 성능 테스트 (0) | 2021.10.03 |
---|---|
koin repository 대상 간단한 unit test (with Rx) (0) | 2021.05.22 |
selectableItemBackgroundBorderless 의 ripple 효과가 안될때 (0) | 2021.01.08 |
프래그먼트 replace시 뷰 상태저장과 불러오기 시점 (with 프래그먼트 viewLifecycleOwner 생성시점) (0) | 2020.11.22 |
[Android Studio] Run 했을때 변경사항이 바로 반영되지 않을경우 (2) | 2020.11.21 |