[iOS/Architecture] UseCase 활용기

안녕하세요 제인입니다 :)

최근에 진행한 개인 프로젝트의 아키텍처를 MVVM-Clean Architecture 로 설계하고, 

각 레이어의 역할을 명확히 구분해 전체 코드의 유지보수성을 높이는 데 초점을 맞추어 개발을 했었는데요,

이 과정에서 특히 UseCase의 역할에 대해 많이 고민을 한 것 같아요!

그래서 제가 저의 방식대로 UseCase를 구성한 내용을 한 번 공유해보려고 합니다.

UseCase란?

UseCase 레이어의 역할을 한 줄로 정의한다면 아래와 같이 정의할 수 있을 것 같습니다.

UseCase는 비즈니스 로직이 위치하는 곳으로, 엔티티로 들어오고 나가는 데이터 흐름을 조정합니다.

 

이 정의를 좀 풀어서 생각해볼게요!

화면에 보여줄 데이터를 원하는 형태로 얻으려면?

1. 네트워크 통신을 통해 DB에 있는 데이터를 가져온다.
2. 요리조리 계산을 해서(= 어떤 로직을 거쳐서) 최종적으로 Entity 획득

 

보통 이런 과정을 거쳐 데이터를 얻게 됩니다.

 

여기서 UseCase 레이어의 역할은

2. 요리조리 계산을 해서(= 어떤 로직을 거쳐서) 최종적으로 Entity 획득

여기서의 '로직'을 의미하게 되는 것 같아요. (제가 원문을 통해 공부하고 프로젝트에 적용해본 결과 느낀 결론은 이렇습니다)

 

저는 MVVM-Clean Architecture 구조로 프로젝트를 설계하였는데요, (다른 패턴과도 적용 가능)

기존 MVVM 패턴에서는 ViewModel이 비즈니스 로직을 담당했었습니다.

그렇다면 MVVM-Clean Architecture 구조에서는 MVVM이 담당하던 비즈니스 로직을 UseCase로 덜어내게 되겠죠?

- ViewModel: 뷰로부터 Input이 들어오면 적절한 Output을 만들어 최종적으로 뷰에 entity를 표출해줄 수 있도록
- UseCase: Repository에 데이터를 요청해서 DB로부터 뷰에 표출할 데이터를 얻고, 이 데이터를 가공 or 데이터 관련 후처리

 

구체적으로 각각 위와 같이 

ViewModel은 Input-Output의 흐름을 조정하는 역할, UseCase는 데이터의 흐름을 조정하는 역할을 담당하게 되어

관심사가 한 단계 더 분리됩니다.

 

처음 클린아키텍처를 공부하며 UseCase가 무슨 역할을 하는지 명확하게 이해하기가 힘들었던 이유는

ViewModel과 Repository 사이에서 대체 얘의 역할이 무엇인지?!?!?! 이해하려고 간단한 코드를 작성해보면,

간단한 작업의 경우 딱히 UseCase에서 수행하게 되는 일이 없어지기 때문.. 이었던 것 같아요!

 

protocol UseCase {
    func execute(request: Request) async throws -> [Item]
}

class DefaultUseCase: UseCase {
    private let repository = DefaultRepository()
    
    func execute(request: Request) async throws -> [Item] {
        let result = try await repository.fetchList(query: request.query, page: request.page)
        return result
    }
}

 

위와 같이 UseCase는 Repository를 execute() 라는 함수로 한번 더 감싸기만 하고.. 거의 코드가 동일해지기 때문에..

그러면 통로 역할만 하는 객체인 UseCase를 둘 필요가 없지 않나? 하는 생각에 뭐지...하는 의문이 많이 들었었는데

더 많은 예제를 찾아보고, 실제로 프로젝트에 적용까지 해보니 어떤 역할을 하는지 감이 잡히더라구요..!

제가 프로젝트에 UseCase를 이용해서 ViewModel의 역할을 덜어낸 과정을 소개해보도록 하겠습니다.

UseCase를 이용해 ViewModel의 로직을 덜어내기

일단, 제가 구현한 로직은 다음과 같습니다.

1. 사용자가 버튼을 누릅니다.

2. ViewModel로 사용자 이벤트가 들어오면 OpenAI API를 이용해 AI의 답변을 요청하는 네트워킹 작업을 수행합니다.

3. 네트워킹에 성공하여 답변을 얻으면 DB의 사용자의 이용 횟수를 업데이트 시킵니다.

 

기존에 UseCase를 사용하지 않았을 때는, (굳이 모든 layer를 꼭 갖추어야 할 필요는 없다고 생각해서 기존엔 UseCase를 사용X)

ViewModel이 Repository로 네트워킹 요청을 하고 Repository는 실제 네트워킹을 수행하는 Service 객체를 이용해 원하는 데이터(ai의 답변 결과)를 fetch 해와서 화면에 보여줄 수 있도록 View에 결과 데이터를 바인딩합니다. 그리고, ViewModel에서 다시 Repository로 DB 데이터의 업데이트를 요청하는 구조였습니다.

기존 코드

final class InputTroubleViewModel {
    // ...
    
    private func fetchData(
        systemContent: String,
        userContent: String
    ) {
        // 데이터 fetch 요청
        repository.fetchResultData(systemContent: systemContent,
                                   userContent: userContent)
        .sink(receiveCompletion: { [weak self] completion in
            switch completion {
            case .finished:
                // 데이터 fetch 성공하면 DB의 유저 정보 업데이트
                self?.saveData()
            case .failure(_):
                self?.state.hasErrorOccurred = true
            }
            self?.state.isLoading = false
        }, receiveValue: { [weak self] result in
            self?.state.result = result.reply
            self?.state.onCompleted = true
        }).store(in: &cancellables)
    }
    
    // DB 유저 정보 업데이트
    private func saveData() {
        repository.updateUserData(userId: UserDefaults.userId,
                               lastUsedDate: Date().today,
                               usedCount: UserDefaults.usedCount + 1)
        .sink(receiveCompletion: { [weak self] completion in
            if case let .failure(error) = completion {
                self?.state.hasErrorOccurred = true
            }
        }, receiveValue: { }
        ).store(in: &cancellables)
    }
}

 

위에서 정리한 내용을 반영해 코드를 리팩토링 해보겠습니다.

UseCase를 도입해 데이터의 흐름을 조정하는 역할은 UseCase가, Input-Output의 흐름을 조정하는 역할은 ViewModel이 담당하도록 하여 뷰모델의 역할을 덜어내볼게요.

개선 코드 - UseCase

protocol ConvertTroubleUseCase {
    func execute(systemContent: String, userContent: String) -> AnyPublisher<ReplyEntity, NetworkError>
}

final class ConvertTroubleUseCaseImpl: ConvertTroubleUseCase {
    private let gptRepository: GptRepository
    private let userRepository: UserRepository
    
    init(gptRepository: GptRepository,
         userRepository: UserRepository
    ) {
        self.gptRepository = gptRepository
        self.userRepository = userRepository
    }
    
    func execute(systemContent: String, userContent: String) -> AnyPublisher<ReplyEntity, NetworkError> {
        return gptRepository
            .fetchResultData(systemContent: systemContent, userContent: userContent)
            .flatMap { [weak self] replyEntity -> AnyPublisher<ReplyEntity, NetworkError> in
                guard let self = self
                else { 
                    return Fail(error: NetworkError.serverError).eraseToAnyPublisher()
                }
                return self.userRepository
                    .updateUserData(userId: UserDefaults.userId,
                                    lastUsedDate: Date().today,
                                    usedCount: UserDefaults.usedCount + 1)
                    .map { _ in replyEntity }
                    .eraseToAnyPublisher()
            }
            .eraseToAnyPublisher()
    }
}

 

위의 UseCase에서는 두 개의 repository를 엮어서 데이터와 관련된 로직을 모두 담당하고 있습니다.

더 자세히 보면, gptRepository를 통해 결과 데이터를 가져오고, flatMap을 사용하여 gptRepository로부터 받은 결과(= replyEntity)를 가지고 추가적인 사용자 데이터 업데이트 작업을 비동기적으로 수행합니다.

만약 중간 과정에서 에러가 발생하면 즉시 종료하고 에러를 반환하고, 모든 작업이 완료되면 ReplyEntity를 반환합니다. 

개선 코드 - ViewModel

final class InputTroubleViewModel {
    // ...
    
    private func fetchData(
        systemContent: String,
        userContent: String
    ) {
        convertTroubleUseCase
            .execute(systemContent: systemContent,userContent: userContent)
        .sink(receiveCompletion: { [weak self] completion in
            if case .failure(_) = completion {
                self?.state.hasErrorOccurred = true
            }
            self?.state.isLoading = false
        }, receiveValue: { [weak self] result in
            self?.state.result = result.reply
            self?.state.onCompleted = true
        }).store(in: &cancellables)
    }
}

 

기존에 ViewModel이 담당하던 역할을 UseCase에서 일부 수행하게 되었기 때문에 훨씬 간단해졌습니다.

뷰모델에서는 UseCase의 결과 값(= ReplyEntity)을 받아서 Output으로 내보내 뷰에 뿌려주거나(여기선 state를 업데이트해주는 방식) 에러가 발생하면 에러에 따른 처리를 해주기만 하면 됩니다. 즉, Presentation에 필요한 정보만 받아 처리할 수 있게 된 것 입니다.

에러 처리 같은 경우에도 뷰모델에서는 최종적으로 한 번만 받아 훨씬 간결해진 것을 확인 할 수 있습니다!

UseCase 도입으로 얻을 수 있는 이점

1. 코드 중복을 방지

기존 코드 vs 개선 코드를 비교하면서 확인할 수 있었죠? (에러 처리의 경우)

핵심 비즈니스 로직을 캡슐화하고, 재사용 할 수 있도록 함으로써 같은 코드가 여러 곳에 산재되는 것을 방지할 수 있습니다.

 

2. 책임을 나누어 커다란 객체를 피할 수 있다.

이것도 뷰모델이 훨씬 간결해진 것으로 위에서 확인할 수 있었습니다.

ViewModel이 비대해지는 문제를 각자 한가지 책임만 가지는 UseCase들을 두어서 해결할 수 있습니다.

 

3. 테스트에 용이

2번과도 이어지는 이점입니다!

한가지 책임만 갖고, 상태를 갖지 않기 때문에 테스트 범위가 명확해집니다.

 

4. 유지보수성 용이

여러 기능이 한 곳에 모여있지 않고, 한 개의 UseCase가 단 하나의 비즈니스 로직만 담당하기 때문에,

UseCase 내부의 일부 로직이 변경되어도 다른 객체나 레이어에 영향을 주지 않게 됩니다.

그러면 수정하기 쉬운 코드가 되겠죠!

 

지금까지 제가 리팩토링한 경험을 정리하면서 UseCase에 대해 더 자세히 공부해보았는데요!

저도 이번 기회로 UseCase에 대한 모호한 개념을 확실히 잡을 수 있었던 것 같습니다.

긴 글 읽어주셔서 감사합니다😊😊

---

[참고 자료]

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

[iOS] 3. Clean Architecture + MVVM 개념 확실하게 이해하기 (Actor가 Entity를 받기까지)

🧙🏻‍♀️ PRND iOS팀의 UseCase 활용기