- 기능정리
- 레이어 정의
- 폴더 정리
- Deployment Target 17 → 16
Clean Architecture 레이어 역할 정의
클린 아키텍처로 구현해 보기로 했으니, 일단 각 레이어의 역할을 나름대로 정의해 보기로 했다.
Model: Presentation, domain 단에서 사용하는 모델
DTO: Repository, API Service 즉 서버와 통신을 위해 사용하는 모델
로 정의했다.
Presentation - ViewModel
- model 사용
- View에 보여줄 데이터를 가공
- UseCase 실행
Domain - UseCase
- model 사용
- 앱의 비즈니스 로직/ 핵심 로직
- 이러한 말들이 너무 모호해서 (유저의 눈에 보이진 않지만) 유저의 요청을 처리하기 위해 짜여진 코드 로 정의 (일단은)
- 일단 도전해 봐야 더 정확하게 정의를 내릴 수 있을 것 같다.
Data - Repository
- data source에서 받아온 데이터를 model로 mapping
API Service (DataSource)
- DTO 사용
- API와 상호작용
UseCase가 Repository에 의존하지 않나?
class UseCase: UseCaseType {
let repository: RepositoryType
}UseCase가 이런 식으로 구성되니, repository에 결국 의존하는 것이 아닌가
라는 생각을 잠시 했는데
repository가 아니라 repositoryType이라는 추상화 프로토콜에 의존,
그리고 repository도 repositoryType에 의존
DIP가 일어난다는 것을 이해할 수 있었다.
[iOS/Swift] 의존성과 의존성 주입
DI와 DIP에 관한 내용은 다른 포스팅에서 확인할 수 있다.
폴더링
위와 같았던 구조를 아래처럼 변경하였음.
Clean Architecture을 기반으로, Presentation, Domain, Data로 구분했고,
의존성 주입을 위한 Dependency 폴더 제작.
해당 폴더에서는 Swinject를 사용하여 객체를 register하고 resolve할 예정.
Deployment Target 변경
당시에 앱 설치를 원하는 분들께서 iOS 17 안 깔려 있는데…
라는 말씀을 많이 하셨지만, 이후에는 팀 프로젝트를 더 지속하지 않게 돼서 결국 타겟을 내리지 못했다.
코드적인 아쉬움도 있지만, 이런 부분에서 너무 아쉬운 것 같다.
일단 NavigationStack 사용을 위해 17에서 16으로 변경하였고,
16에서 사용할 수 없는 코드들은 삭제하였다.
