이번 포스트에서는 제 프로젝트를 예시로 iOS 프로젝트에 MVVM+Clean Architecture 구조를 적용해보겠습니다!

저번 포스팅을 작성하고도 헷갈리는 부분들이 많아서 계속해서 정보들을 찾아봤습니다. 그러다가 아주 좋은 포스트를 발견했는데, 오늘은 해당 포스트를 기반으로 내용을 정리해보겠습니다. 제 포스트를 보시는 분들도 아래 포스트를 자세히 읽어보는 것을 추천합니다 👍

Clean Architecture and MVVM on iOS

MVVM + Clean Architecture

해당 게시물을 보면 위와 같이 크게 세 가지 레이어로 구성을 나누었습니다. 이런 의문점이 들 수 있습니다. 저번 포스트에서는 4가지로 나뉘었는데 Clean Architecture 구조가 아닌거 아닌가요?

Clean Architecture의 핵심은 의존성에 있습니다. 안쪽 레이어부터 바깥 레이어로의 의존성 방향이 있지만 않으면 레이어의 개수나 구조는 아무 상관이 없죠. 따라서 위와 같은 구조도 아무 문제가 없는 것입니다!

위 게시물에 따른 레이어의 종류는 아래과 같습니다.

• Presentation Layer
• Domain Layer
• Data Layer

Domain Layer

Domain Layer는 가장 안쪽의 레이어입니다. 따라서 아무런 의존성을 가지지 말아야하고, 독립되어 있어야합니다. 이로서 얻을 수 있는 이점으로는 아무론 종속성이 없기 때문에 테스트하기 매우 간편하다는 점입니다. 다른 파일의 수정이나 추가 없이 오직 Domain Layer에만 집중해도 결과가 도출되죠.

Entities, Use Cases, Repository Interfaces들이 Domain Layer에 속합니다.

Presentation Layer

Presentation Layer에는 말 그대로 UI 요소들이 속합니다. 대표적으로 View Model이 여기에 속하여 Use Cases의 함수들을 호출합니다.

Presentation Layer는 오직 Domain Layer에만 종속되어 있습니다.

Data Layer

Data Layer에는 Repository와 Data Sources들이 속합니다. 여기서 Repository는 외부의 Data Sources로부터 데이터를 받아올 때 사용되고, Data Sources들은 로컬 데이터들을 의미합니다.

Data Layer 또한 오직 Domain Layer에만 종속되어 있습니다.

✔️ 적용하기

위 포스트와 제가 배워온대로 그림을 그려보면 아래와 같이 나와야합니다.

그런데 구조가 이렇게 되면 Use Case가 Repository를 호출하는데, 참조 관계는 반대로 되어 있는 아주 잘못된 현상이 발생하게 됩니다. 안쪽 레이어가 바깥 쪽 레이어를 참조하다니, Clean Architecture의 규칙을 깨부수고 있네요 😫

하지만 Use Case는 꼭 Repository에 Request를 해야합니다. 이럴 땐 어떻게 해야할까요?

바로 위와 같이 중간에 한 단계를 더 거치게 만들면 됩니다. 위 레이어 설명에서 Domain Layer에 Repository Interface가 포함되어 있었죠? 이 친구가 바로 여기에 쓰입니다.

Repository Interface는 프로토콜의 형태로서 Use Case와 같은 레이어에 속해있지만, 실제 구현은 Data 레이어에 있게 됩니다.

데이터의 흐름을 살펴보고 실제 구현에 들어가보겠습니다.

1. View가 View Model의 함수를 요청한다.
2. View Model이 Use Case를 실행한다.
3. Use Case가 User와 Repository로부터 얻은 데이터를 활용하여 결과를 도출합니다.
4. 이 때, Repository는 네트워크(ex: API)와 Local DB(ex: Realm)로부터 데이터를 받아와 Use Case에 제공합니다.
5. Use Case에서 도출된 결과를 거꾸로 View에 제공합니다.