[아키텍쳐] MVVM (clean-architecture) 이란

오늘은 가장 많이 쓰이는 MVVM 패턴에 대해 다시 정리를 해보려구 한다.

 

 

기존 MVC 패턴이 View와 Controller 간 분리가 되지 않아 비대해진다는 문제점이 있었다.

MVVM 패턴은 view, view model, model 이렇게 3가지 분리를 통해 그 문제점을 해결한다

앞으로는 model의 변화를 view model이 책임지고 view는 model가 직접적인 연결 없이 view model을 통해 view 자신을 업데이트 한다. 

 

여기까지는 내가 알고 있던 MVVM 패턴이었구 MVVM 패턴에 Repository ?? 를 쓰는 경우를 발견해서 궁금해서 정리 해보려고 마음 먹게 되었다. 

아래 깃헙을 참고하여 정리해보려구 한다.

https://github.com/kudoleh/iOS-Clean-Architecture-MVVM

GitHub - kudoleh/iOS-Clean-Architecture-MVVM: Template iOS app using Clean Architecture and MVVM. Includes DIContainer, FlowCoor

 

우선 클린 아키텍쳐란 ? (클린 코드 .. 👍)

Robert C Martin(Uncle Bob)님이 제안하셨는데, 아래사진처럼 앱 아키텍쳐를 구성한 것을 Clean Architecture라고 한다.

https://blog.coderifleman.com/2017/12/18/the-clean-architecture/

The Clean Architecture

이 한글  번역본을 참고하였다 !

 

우선 원들은 계층을 띄고 있다.

안쪽의 원들은 정책(Policy)이고 바깥 원들은 메커니즘(Mechanism)이다.

이 원들 사이에는 규칙이 존재하는데 바깥쪽 원에서 선언된 규칙은 안쪽 원으로 들어올 수 없다. 즉 참조, 사용 모두 안된다.

이 규칙을 통해서 의존 관계를 유지할수 있다고 한다.

 

1.엔티티

엔티티는 대규모 프로젝트 레벨의 비지니스 규칙을 캡슐화 한다. 대규모 프로젝트가 아닌 하나의 애플리케이션을 작성할 뿐이라면 엔티티는 애플리케이션의 비지니스 객체로서 가장 일반적이고 고수준의 규칙을 지닌다. 변동 가능성이 적다. 

 

2. 유즈케이스

이 계층의 소프트웨어는 엔티티로부터의 데이터 흐름을 조합한다. 이 계층으로부터의 수정 사항이 엔티티에 영향을 주지 않을 것으로 기대하며 데이터베이스, UI 또는 공통의 프레임워크의 변경으로부터 영향 받지 않을 것도 기대한다. 하지만 애플리케이션의 조작에 대한 변경은 유즈케이스에 영향이 있고 이 계층의 소프트웨어에 영향이 있을 것을 기대한다. 

 

3. 인터페이스 어댑터

이 계층의 소프트웨어는 어댑터의 집합이다. 유즈케이스와 엔티티에 있어 용이한 형식으로부터 데이터 베이스나 웹 등 외부 기능에 용이한 형식으로 데이터를 변환한다. 예를 들어 GUI의 MVC 아케텍쳐를 완전히 내포한다. 프레젠터, 뷰, 컨트롤러 모두 여기에 속한다. 

 

4. 프레임워크와 드라이버

가장 바깥쪽의 계층은 데이터베이스나 웹 프레임 워크 등 일반적으로 프레임워크나 도구로 구성된다. ex) Network, CoreData

 

사실 잘 이해가 가진 않지만 아는 단어가 나오는 부분은 드문 드문 연결하니 알것 같기도 하고 그렇다.

https://amara.org/ko/videos/0AtjY87egE3m/url/1216370/

Video Subtitling, Captioning and Subtitle Translation - Amara Subtitling

자막 동영상도 있다 하니 나중에  참고용으로 보아야겠다.

 

 

예제 코드 분석해보기

예제 코드의 폴더 계층 구조이다. 

크게 영역은 Domain, Presentation, Data 이렇게 세 부분으로 나뉜다.

 

Domain 부분에는 Entities, UseCase, interface가 있는데 interface는 자바 상속관계에서 보던 그 interface인거 같고 repositories 폴더를 보면 Data 아래 repositories에서 사용할 클래스들에 대한 프로토콜이 정의되어 있다.

 

계층 구조를 다르게 구조화 하면 아래 그림과 같다.

user는 Presentation 의 View와 interaction 하고 그 사이를  Presenter가 매개한다. 이 역할을 MVVM 패턴에선  ViewModel이 주도한다. viewModel에선 하나 이상의 usecase를 excute 하기 때문에 Domain Layer와 interact할 수  있다. 

 

Data layer에선 API, DB를 담당한다.

 

Domain layer에 있는 repositories protocol을 구현한 클래스들이 있고 DB를 구현한 Core Data들이 존재한다.

 

총 정리하면 아래 그림과 같다.

Domain Use Case와 Data Repository 사이에 Repository Interface Dependency Inversion이라는게 있다.

 

한국말로 하면

의존성 역전 원칙 

이다.

 

1. 고수준 모듈은 저수준 모듈에 의존해서는 안 됩니다.

2. 추상화는 세부 사항에 의존해서는 안됩니다.

 

즉 우리가 Repository를 구현할시 Domain -> Data의  의존성을 느슨하게 하기 위해 protocol 형식으로 변경에 확장성을 용이하게 한 것을 의미한다.