💎 MVVM이 만능...?
MVVM패턴을 공부할 때는 MVC의 패턴의 문제점들을 완벽하게 해결해 줄 수 있을것이라 생각했다.
하지만, 이번에 작업을 진행하면서 MVVM 패턴도 한계가 존재한다는 걸 알았다. 예제 단위의 간단한 앱구조에서는 보이지 않던 문제들이 실제 앱에서는 나타나기 시작했다.
게다가, 앱의 핵심 기능들이 주기적으로 추가 및 수정되고 삭제되면서 MVVM패턴으로 구성되었다 하더라도 이를 대응하기에는 명확한 한계들이 나타났다.
✏️ 문제
- MVC의 문제가 결국 다시 나타났다. 복잡하고 거대한 컨트롤러 대신 복잡하고 거대한 뷰모델이 생겼다.
- 각각의 부분이 독립적이기에 모듈화가 되어있긴 했지만, 뷰모델 내부에 있는 핵심 기능들이 복잡해짐에 따라, 결국 앱의 핵심 로직들을 파악하기 어려워지고, 이는 핵심 로직의 수정이 어려워지고, 삭제나 추가에 있어서 부담감이 심해졌다.
- 핵심 로직의 테스트 작성이 어려워졌다. 이는 복잡해진 로직이 뷰모델에 모두 들어가면서, 뷰모델의 테스트 코드도 길어지고, 테스트를 위한 테스트 코드를 작성하게 되었다.
✏️ 해결하려면
- 사실, 제목에도 써놨듯 클린 아키텍처가 이러한 문제에 대한 해결법으로 많이 제시된다. 여러 관점과 설명들이 있지만, 거두절미하고 나는 이 클린 아키텍처에서 제시하는 레이어 단위의 추상화에 집중하였다.
- 앱의 핵심 기능(유즈케이스, 비즈니스 로직)을 하나의 레이어로 분리해 관리하는 것이다. 이는 도메인 레이어가 된다.
- 이렇게 앱의 비즈니스 로직을 뷰모델에서 떼어와 주요 기능별로 추상화 하여 각각의 모듈로 만들어 관리하면, 수정, 추가, 삭제에 바로바로 쉽게 대응이 가능하다.
- 테스트도 용이해진다. 각 비즈니스 로직을 추상화 했기에, 그 객체를 테스트하면 핵심 로직에 대한 테스트가 된다.
✏️ UseCase?
- 사실, 대부분
UseCase라는 표현을 쓴다. 유즈케이스라는 단어 자체가 딱 이를 표현하기에도 좋고.. - 나는 그럼에도
Service라고 표현하고 싶다. - 비즈니스 로직은 결국 앱에서 사용자에게 제공하는 기능이고, 이는 서비스라는 표현이 좀 더 직관적이라고 생각했다.
LoginUseCase보다는LoginService가 좀 더 직관적으로 읽히지 않나..? 🤔
✏️ ViewModel
- 그림에서는 뷰와 뷰모델을 나누어 두었지만, 사실상 뷰모델은 Presentation 레이어에 속한다고 보는게 맞다고 생각했다.
- 사실 생각해보면 뷰모델이라는 이름 자체가 "뷰(View)에 필요한 데이터(Model)"이다. 서비스(유즈케이스)에 요청한 데이터를 뷰에 보여줄 데이터로 변환하는 역할을 한다.
- 이전에는 뷰모델에 비즈니스 로직과 뷰에 보여줄 데이터로 변환하는 로직이 같이 있었다. 결국 복잡할 수 밖에 없다.
- 이 두가지 로직을 레이어로 나눔으로써 각각의 객체의 역할을 더욱 명확해졌고, 뷰와 비즈니스 로직이 완벽하게 분리됨으로써 테스트도 용이해졌다.
✏️ Result
- 결과적으로 각 로직의 레이어를 어떻게 설정하고, 각각의 기능을 어떻게 모듈화 해야 하는지 고민하게 되었고 자연스럽게 Presentation과 Domain이 나뉘게 되었다.
- 나아가 각 레이어를 프로토콜을 이용해 의존성을 덜어주고, 객체간 결합도도 낮추어서 더욱 테스트에 용이하고, 독립적인 객체를 만들 수 있게 되었다.
