Clean Architecture 1(Layer 알아보기)

어떻게 하면 관심사 분리부터 유지보수에 용이한 구조를 만들 수 있을까 고민이 들어 Clean Architecture에 대해 공부한 걸 정리하려 합니다. 

 

Clean Architecture를 보면 기본 컨샙은 다음과 같습니다.

출처: https://tech.olx.com/clean-architecture-and-mvvm-on-ios-c9d167d9f5b3

 

Dependency Rule: 

1. 바깥 영역(소스코드 영역)에서 Domain 영역으로 의존성을 가지며 절대 의존성 방향이 반대가 되면 안 되는 Rule을 가집니다. 이게 클린아키 택처의 핵심입니다.

2. 내부 코드에서 외부 코드에서 사용한 클래스나, 메소드, 변수를 언급하는 것도 의존성 방향의 위배됩니다. 

 

예로 iOS ViewModel이 비즈니스 로직에 따라 뷰가 업데이트되는 것처럼 말입니다. 그 반대가 되면 뷰 Layer에 의해 비즈니스 규칙이 변경되는 즉, 내부 영역에서 외부 영역의 영향을 받는 유지보수가 힘든 코드가 될 거 같습니다.

 

영역 소개

Domain 

- Entites

비즈니스 규칙이 캐슐화 된 것으로 클래스 메소드, data 구조로 설계될 수 있습니다.

비즈니스 규칙에 의해 생성된 만큼 프레임워크나 기술 영역(보안 등)에서 바뀔 확률이 가장 적은 영역입니다.

 

- Use Cases

특정 비즈니스 규칙(Eintites)을 포함하는 영역으로 비즈니스 규칙의 사용을 구현합니다.

예를 들어 제품 구매와 같이 에플리케이션이 엔티티와 어떻게 작용할지 로직을 작성하는 영역입니다.

외부 시스템 (DB), UI나 데이터 저장과 같은 외부 관심사로부터 분리되어 있습니다.

 

예를 들어, 쇼핑 앱을 만든다고 가정해 봅시다. 엔티티는 이름, 가격, 수량과 같은 속성을 가진 제품일 수 있습니다. 유스 케이스는 "제품 구매"가 될 수 있으며, 제품 재고 확인, 수량 업데이트, 결제 처리와 같은 단계를 포함합니다.

 

Presenters

UI(UIViewControllers or SwiftUI Views)가 포함된 영역입니다.

자세히 말하면, Viewmodel, Controlller가 하나 또는 여러 개의 Use Case를 실행하고 View는 이 실행에 따라 표출됩니다.

이 Layer는 Domain Layer를 Depend하고 있습니다.

 

Data Layer

하나 또는 여러개의 Data soruce를 구현하는 Repository.

*) data source 는 Local(persistent database), Remote(fire base Storage)를 말합니다.

Repository는 Data source를 어플리케이션에서 사용할 수 있도록 data구조로 convert(Domain Models에 Decodable를 준수해 맵핑하는 것처럼).

Presenter와 마찬가지로 Domain Layer를 의존하고 있습니다.

 

Layer 도식화

 

Dependency direction

위 그림은 각 Layer의 컴포넌트가 Dependency direction 방향을 도식화한 것입니다.

주황색 화살표는 Data Flow의 request, response 요쳥으로 각각 이어져 있다는 뜻으로 Dependcy Direction의 방향이 아닙니다.

또한 Data Lyaer와 Domain Layer의 의존성 역전이 발생하는 것을 볼 수 있습니다.

 

★Dependcy Inversion

의존성 역전이랑 의존성 방향을 역전하는 게 아닙니다. (Domain Layer -> Data Layer)
중요한 점은 의존성의 '방향'이 아니라, "어떤 계층이 어떤 추상화를 소유하고 있느냐"입니다.
이렇게 되면 Domain Layer는 Repositories 유형(CoreData, SQLLite, Network API)에 의존을 받지 않습니다.

---

 

Clean Architecture의 Data의 흐름은 다음과 같습니다.

1. UI는 ViewModel 메소드를 호출합니다.

2. 뷰 모델은 Use Case를 실행합니다.

3. Use Case의 경우 User가 상호작용 하며 생성한 데이터를 Data Repository와 결합합니다.

4. 각 Repository는 Persistence DB, Remote Data(Network) 로컬이나 원격 Repository에 저장하거나 데이터를 return 합니다.

5. 위 작업이 완료가 되면 이후 다시 UI까지 흐름이 진행됩니다.(작업완료 알림 표출 등 UI적 요소)

 

Dependency Direction

위 그림에서 의존성 방향은 다음과 같습니다.

Presentation Layer -> Domain Layer <- Data Repositories Layer

Presentation Layer(MVVM) = ViewModel, UIViews

Domain Layer = Entities, Use Cases, Repsitories Interfaces

Data Repositories Layer = API, Persistence DB, Repositories Implementations

 

여기까지 Clean Architecture 구성에 대해 알아봤는데요, 다음 글에선 각 레이어층에 대해서 예제 코드를 보며 알아보는 시간을 가지도록 하겠습니다. 읽어주셔서 감사합니다.

 

 

Reference

https://tech.olx.com/clean-architecture-and-mvvm-on-ios-c9d167d9f5b3

Clean Architecture and MVVM on iOS

https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html

Clean Coder Blog