이해를 위해 직접 ppt로 그리면서 적어보았습니다
전체적인 흐름
Service를 UseCase라고 생각해주시면 될 것 같습니다. 아래 글에서는 'Service(UseCase)' 이와 같이 표기했습니다.
Presentation Layer
MVVM
View는 뷰를 선언하고 레이아웃을 처리하고 애니메이션 처리 등 UI를 그리는데에만 집중합니다.
사용자에게 들어온 Input 이벤트를 ViewModel에게 전달하고, 변경된 값을 View에 그립니다.
변경된 값을 감지하는 방법으로는
- Observer Pattern을 기반으로 한 RxSwift나 Combine를 통해 ViewModel안에 있는 "화면에 그릴 값"들을 감시하는 방법
- didSet과 closure를 통해서 값이 업데이트가 됐다는 이벤트를 받는 방법
이정도가 있습니다. (+ KVO)
ViewModel은 View에서 별다른 연산없이 그냥 가져다가 화면에 뿌려줄 수 있게끔 가공된 데이터를 가지고 있습니다.
비즈니스 로직은 Service(UseCase)에게 넘겨줍니다.
+++
화면전환은 Coordinator가 담당하게끔 함으로써 더 분리가 가능하다.
Domain
Service(UseCase)는 비즈니스 로직을 담고 있는 앱의 가장 핵심적인 영역입니다.
복잡한 연산이나 모든 로직이 이곳에 들어갑니다.
Data
Repository는 서버나 로컬DB 등으로부터 응답을 받아 Service에게 넘겨줍니다.
모델은 총 3가지가 존재한다.
모델은 총 3종류가 있습니다. 핵심적인 내용은 위의 사진과 같습니다.
- Entity는 서버에서 받은 응답. 그대로의 날 것의 구조체입니다.
- Model은 서비스를 구현하는데 우리에게 필요한 값들만 추출해서 만든 모델로, 현재 앱의 상태(state)를 담고 있습니다.
- ViewModel은 이름 그대로 "Model for View"입니다.
View에 보여질 데이터를 가지고 있어 View는 해당 값을 가져다가 화면에 입히면 됩니다.
Service(UseCase)가 핵심.
흐름도에서 보면 Service(UseCase)에게 모두 존댓말을 붙이는 것을 볼 수 있습니다.
이는 Service(UseCase)가 가장 핵심적인 부분임을 나타내기 위해 윗사람 컨셉으로 해주었습니다.
그 이유로는 Service(UseCase)에는 모든 앱의 핵심적인 부분이 모두 들어가 있습니다.
- Entity: Entity를 받아 Model로 가공하는 작업을 이곳에서 수행하기에 Entity를 알고 있습니다
- Model: Model로 가공하여 ViewModel로 넘겨주기 때문에 Model 또한 알고 있습니다.
- Logic: 모든 비즈니스 로직은 이 곳에서 실행되기 때문에 로직 또한 알고 있습니다.
결론
이렇게 계층을 분리하면 확실히 앱이 아무리 커지고 코드가 아무리 많아져도 쉽게 감을 잡을 수 있을 것 같습니다.
또한, 이렇게 계층으로 분리하게 되면 각각의 책임이 명확하고 각자의 역할에만 집중하기 때문에 변경사항에 정말 유연하게 대처할 수 있겠구나 싶습니다. 서로간의 의존도가 낮기 때문에 테스트시에도 용이하다는 장점도 있습니다.
그에 대한 트레이드 오프로 많아지는 파일과 간단한 로직에도 복잡해지는 단점은 있겠네요.
Reference
'Dev > Swift 내 정리' 카테고리의 다른 글
| [Swift 기본기] weak와 side table (5) | 2024.03.15 |
|---|---|
| [iOS] CGPoint, CGSize, CGRect, Frame, Bounds (0) | 2023.05.08 |
| [Swift] Closure Capture list, ARC, AnyObject까지 연결지어서 정리 (0) | 2023.04.23 |
| final 키워드를 왜 사용할까?? 정리 (0) | 2023.04.05 |
| [Swift]비동기(Async) ≠ 동시성(Concurrency) feat. 병렬성(Parallel) (0) | 2023.03.16 |
댓글