원문 보러가기 -> 런로그 위키
🚨 문제 발생
- 유즈케이스 설계 회의 과정에서 유즈케이스가 어떤 책임을 가지는지, 어떤 게 유즈케이스에 속하는지 명확히 이해하지 못해서 추가로 더 만들어야하는 함수가 생겼다.
🧐 원인 분석 (Root Cause Analysis)
- 그래서 오늘의 트러블 슈팅 문서는, Repository와 Usecase 비교해서 이해하기!이다.
💡 해결 과정
Repo vs UseCase
UseCase를 내가 이해한 대로
UseCase는 단순히 DB나 Network처럼 데이터 처리만 하는게 아니라, 서비스의 비즈니스 로직을 담당하는 클라이언트 내부에서 처리하는 기능도 제공한다
그동한 ~~Manager로 작성해왔던 것을 UseCase가 포함할 수 있다.
네트워크에서 데이터를 가져오거나, 캐시에서 불러오고 가공하는 로직을 포함할 수 있다.
Repository를 내가 이해한 대로
Repo는 DB 매니저와 같다.. 기본적으로 CRUD를 지원한다. → data access 처리
- Repository는 데이터 소스 (DB, Network 등)와 상호작용하는 계층
- 보통 Core Data, UserDefaults, API 요청 등을 캡슐화하여 제공
- 즉, Repo는 단순한 “데이터 저장/조회” 용도로만 사용됨
- CRUD(Create, Read, Update, Delete) 기능을 기본적으로 제공
회의 과정에서의 알게된 것과 추후 정리한 것
오늘 Usecase 설계 회의에서는, 뷰모델에서 처리해줘야하는 것을 작성하고 이를 통해 UseCase의 func을 정리하는 방식으로 진행했다. 그렇게 생각하니 repo는 crud하고, 뷰모델에서 실제로 어떤 기능을 사용하고, 유저 인풋등을 관리하고, usecase에서 이 사이의 로직을 모두 담당한다고 생각하기 편했다.
✔ 뷰모델에서 처리해야 하는 기능을 먼저 정리한 후, 이를 기반으로 UseCase의 메서드를 설계
✔ 이렇게 접근하니 전체 구조가 더욱 직관적으로 이해됨
✔ Repository는 기본적인 CRUD를 제공
✔ ViewModel은 유저의 입력을 받고, 어떤 기능을 사용할지 결정
✔ UseCase는 ViewModel과 Repository 사이에서 모든 비즈니스 로직을 처리
🎯 결과 및 교훈
관심사 분리 명확히 하는게 중요하다. Usecase가 속하는 도메인 레이어는 앱의 핵심 비즈니스 로직과 관련되어있는 레이어이다. 따라서 유즈케이스도 도메인 레이어의 원칙과 책임을 수행하는 역할을 해야한다. 그래야 그 폴더에 존재할 수 있음!
