클린 아키텍쳐 톺아보기 [2 / 3]

[seungchan2]

Presentation Layer

플랫폼에 의존하지 않고, Unit Test에 용이

화면에 그리는 게 어떤 의미인지 알고 있으므로, 사용자 입력이 왔을 때 어떤 반응을 하는지에 대한 판단

View + ViewModel

ViewModel은 UI이벤트가 발생하면 '무엇'을 해야하는지 알고, UseCase를 요청 후 View에 업데이트 알림 역할

Domain Layer

비즈니스 로직 계층

저장소에 관한 Interface가 포함

다른 프로젝트에서도 재사용 될 수 있도록, 다른 부분에 의존하지 않고 의존을 받는 상태

Model

도메인 모델 (struct)

REST API로 얻은 외부 데이터 포함

Translater

Mapper 역할

entity와 domain 모델 사이

Use Case

비지니스 로직

(Repository)

Interface 형태

데이터 소스 객체 변경하여 외부 API 호출 / 로컬 DB / mock 객체

Domain과 Data의 인터페이스 역할 protocol

Data Layer

DataStore + Entity

Entity

DataStore에서 사용되는 데이터를 저장한 모델

REST API의 Request / Response를 위한 JSON을 위한 Codable 모델

로컬 DB에 저장하기 위한 struct 모델

Data Store

데이터 입출력이 실행되는 곳

Presenter(ViewModel) vs UseCase

• ViewModel에 비즈니스 로직을 넣는 경우는 잘못된 접근

  • 비즈니스 로직은 UseCase에 존재

• ViewModel의 역할은 UI이벤트들이 발생하면 '무엇'을 해야하는지 알고 있는 것

  • '무엇'을해야 하는지 알고 있기 때문에 UseCase를 실행시키고 UI에 업데이트를 알리는 역할

• 비즈니스 로직은 앱에서 사용자와의 상호작용 아닌 업무 요구 사항을 담고 있는 것

  • 비즈니스 로직: "개발팀 외부의 사업 부서 사람도 알고 있어야 하는 로직"

Model vs Entity

• Model은 Entity로부터 앱에서 사용하고자 하는 모델로 변경한것

  • Entity는 codable과 같은 json에서 파싱되는 모델

• 만약 Model과 Entity차이가 별로 없다면 둘중 한 모델만 사용해도 무방

의존 관계에 따른 데이터 흐름

1. View에서 이벤트가 발생 -> Presenter(ViewModel)에서 '무엇'인지 판단
2. Presenter는 UseCase를 실행
3. UseCase는 User와 Repository를 결합
4. 각 Repository는 network, DB관련 Store에서 데이터 반한
5. 다시 UI에 업데이트: Store -> Repository -> UseCase -> ViewModel -> View(UI)