최근 이직한 회사에서 사내 카페 주문앱을 만들게 되었다.
이름은 댕댕이 바리스타 사용자앱.
경력을 시작하고 나서 처음으로 밑바닥부터 만드는 신규 프로젝트를 맡게된 것이다.
일단 구조를 짜자.
사내보안상 코드를 공개 할 수 없어 내 깃허브에 있는 비슷한 구조의 프로젝트를 가져와보았다.
전체코드는 여기서 볼 수 있다.
이렇게 클린아키텍쳐로 짰다.
클린아키텍쳐에서는 앱의 계층을 Presentation, domain, data로 나눈다.
Presentation은 Activity, Fragment 같은 UI를 담당하고
domain은 앱의 유스케이스를 정의하고
data는 외부환경으로부터 데이터를 얻는다.
나누는 이유는 한가지 변경사항이 모든 곳에 영향을 끼치지 않도록 하기 위해서이다.
예를들어 서버와 API 통신을 하는데 서버측에서 보내는 응답의 형식이 바뀌였다고 하자.
그러면 그 데이터를 쓰는 모든 코드를 바꿔야할 것이다.
만약 앱의 계층을 나눈다면 data 계층만 바꾸면 된다.
domain과 data 계층이 repository라는 인터페이스로 느슨하게 연결되어있기 때문에 가능한 일이다.
domain은 data 계층이 repository를 어떻게 구현하든 인터페이스에 나와있는 항목들만 신경쓰면 되기 때문에 data 계층의 변경에 영향을 받지 않는다.
또, Presentaion은 domain만을 바라보기에 data계층의 변경에 영향을 받지 않는다.
내가 클린아키텍쳐를 적용하면서 가장 크게 느낀 장점이였다.
API는 자주 추가되거나 삭제, 변경되므로 이렇게 구조를 짜놓으면 편했다.
또, 레이어들은 각각의 역할에 따라 분리되어있으므로 한눈에 보기도 쉽고 유지보수도 간편했다.
(합쳐져있으면 보기도 불편하고 한 부분을 고치는데 모든 부분을 고려해야한다)
실제로 이 클린아키텍쳐를 짜면서 의문이였던 점은
의존성이였다.
이상적인 구조와는 조금 다른 형태를 띄게됬다.
내가 생각한 이상적인 구조는 data에서 서버와 API 통신을 하고 그 결과를 domain이 앱에서 활용할 데이터로 변환시킨 후 그것을 Presentation에서 사용하는 구조였기 때문에 위의 그림을 이상적인 구조로 생각했다.
domain에서 repository의 구현에 대해 신경쓰지 않기 위해서는 repository interface를 만들고, data에서 구현한다.
나의 경우 MainRepository를 구현했는데 이것을 Repository 인터페이스 형태로 domain의 usecase에 주입하기 위해서는 Presentation이 MainRepository를 알아야했다.
때문에 Presentation은 data 계층에 의존성을 가진다.
또 data계층에서는 domain의 repository 인터페이스를 구현해야할 의무가 있으므로 자연스레 domain에 의존성을 가지게된다.
구현상 어쩔 수 없는 구조로 보인다.
그래도 data에서 받아온 데이터를 domain에서 앱에서 쓸 데이터로 가공 후, Usecase를 통해 Presentation으로 제공하는 구조는 변함이 없었다.
'안드로이드 앱개발' 카테고리의 다른 글
딥링크, 앱링크, 디퍼드 딥링크, 다이나믹링크와 광고의 연결 (0) | 2022.03.28 |
---|---|
안드로이드 라이브러리 만들때 유의사항 (0) | 2021.12.31 |
레거시 코드 리팩토링과 코틀린 마이그레이션 (0) | 2021.09.15 |
Service (0) | 2021.09.04 |
Permission (0) | 2021.09.04 |