[안드로이드] UseCase를 왜 쓰나요?

이걸 디자인패턴에 넣을까,, 안드로이드에 넣을까,, 하다가 안드로이드에 넣습니다!

개발하고 있는 앱의 구조를 휘리릭 바꿔버렸어요. MVVM 구조를 따라서 개발을 하고있는데(따른다고 따르고 있었는데;) 개발을 하면 할수록 이 구조가 맞나,,? 싶더라구요. 공부를 더 해보니까 역시 잘못된 방향으로 가고 있었습니다 ^0^

휘리릭 바꾼 구조에서 UseCase를 야무지게 쓰게 되었는데요, UseCase를 처음 접했을 때 든 질문이 있었습니다. UseCase가 행동의 최소단위인 건 알겠어,

왜 UseCase를 쓰지?

이 질문의 답을 얻기 위해 검색하다가 아주 도움이 된 글이 있었는데 그 글을 짧게 옮겨보겠습니다! 원글은 글 하단에 적어두겠습니다!

Layered Architectures and the Application Layer

Presentation Layer, Domain Layer, Data Layer는 클린 아키텍처를 공부할 때 흔히 접한 내용이죠? 그렇다면 Application Layer는 뭘까요? 왜 초면일까요?

• Application Layer: Domain Layer로의 데이터 흐름을 이어 소프트웨어가 해야 할 일을 정의한다.
• 보통 Application Layer는 Domain 패키지 안에 넣어 잘 모르고 있었습니다.
  • 왜 그렇게 했을까요? -> 둘 다 비즈니스 로직을 담습니다.
  • Domain Business Logic: data 뿐만 아니라 process(enterprise-wide business logic)도 포함하는 model을 이용
  • Application Business Logic: Domain model을 검색하고 저장하기 위해 UseCase를 이용(Data Layer로의 포트 역할을 하는 Repository를 통해)

즉, Domain Layer와 Application Layer는 같은 토픽을 커버하기 때문에 함께 묶였던 겁니다!

UseCase 사용 이유

위에서 Application Layer와 UseCase에 대해 알아봤으니 이제 UseCase 사용 이유에 대해 알아보겠습니다.

Avoid “God” ViewModels

관심사를 분리하지 않으면 어떻게 될까요? 모든 걸 다 알고 모든 것에 의존성을 갖는 Gob Object가 됩니다.

다음 두 케이스를 비교해 보겠습니다.
#1. UseCase를 쓰지 않는 ViewModel
#2. UseCase를 쓰는 ViewModel

#1에서는 ViewModel이 Repository 등 모든 것에 의존하게 됩니다. 그에 비해 #2는 그 의존도가 UseCase로 옮겨가겠네요! 즉, data logic이 이동해 더 가벼운 ViewModel을 갖게 됩니다~

또, 만약 기존 Repository에 다른 Repository의 ourput이 parameter로 필요해진다면 어떻게 될까요? #1은 Repository를 ViewModel에 추가해야겠네요! #2는 ViewModel에 전혀 영향을 주지 않고 변경을 받아들일 수 있습니다.

마지막으로! 비슷한 ViewModel이 있다면요? #1은 중복된 data logic 코드를 작성해야 겠죠? #2는 이미 구현한 UseCase를 재사용하면 됩니다 !!

“Useless Use Cases”

class GetWeatherInfoUseCase(private val weatherInfoRepository: WeatherInfoRepository) {
    suspend fun getWeatherInfo(
        units: String,
        lat: String,
        lon: String
    ) = weatherInfoRepository.getWeatherInfo(units, lat, lon)
}

이렇게 Repository의 method만 호출하고 아무것도 하지 않는 경우에도 UseCase를 사용해야할까요? 네 !!!

이유 1. 일관성
이유 2. 미래의 변경에 대해 코드를 보호
클린 아키텍처에서 중요하게 생각하는 게 요구사항이 바뀌었을 때 그 변화를 쉽게 적용하는 것 입니다. 즉, 수정을 최소화 하자는거죠! 한 Repository가 여러 ViewModel에서 쓰이고 있는데 그 Repository가 바뀐다면요,,? 해당 Repository를 사용하는 모든 ViewModel을 수정해야겠죠?(OCP 위배) UseCase를 쓴다면 간단합니다! 그 구현만 수정하면 돼요~

The “Screaming Architecture”

UseCase를 사용한다면 그 UseCase를 보는 것만으로 코드를 이해할 수 있습니다. 그 자체로 해당 코드가 뭘 하는지를 알려주죠~ 새로운 개발자가 팀에 들어와도 쉽게 코드를 이해할 수 있겠죠?!

정리

UseCase를 사용하면 전체적인 코드 파악과 의존성이 낮아지므로 유지보수에 용이해진다.

왜 UseCase를 써야하는지 이해가 쏙쏙 되었죠?

Clean Architecture is a Use Case driven architecture, hence each repository method exists only because it is supporting a Use Case.

UseCase를 씁시당🔥

출처

Why you need Use Cases/Interactors