[iOS] Clean Architecture for iOS

🤔 탄생한 이유?

---

 

그 동안 여러 시스템 아키텍처가 존재해왔습니다.

• Hexagonal Architecture
• Onion Architecture
• Screaming Architecture
• DCI
• BCE

이런 여러한 아키텍처들은 세부사항들은 다르지만 동일한 목표를 가지고 있는데 그것은 관심사의 분리라는 목표입니다. 해당 아키텍처들은 소프트웨어를 여러 레이어(layer)로 나누어 목표를 달성합니다.

레이어 종류에는 비즈니스 규칙 레이어가 하나이상 존재하고 인터페이스용 레이어가 존재합니다.

 

각각의 아키텍처들의 생산성

---

1. 프레임워크에 독립적입니다.
   1. 아키텍처는 기능이 포함된 소프트웨어 라이브러리의 존재 여부에 의존하지 않습니다. 이를 통해 시스템을 제한된 제약 조건에 가두는 대신 이러한 프레임워크를 도구로 사용할 수 있습니다.
2. 테스트가 가능합니다.
   1. 비즈니스 규칙은 UI, 데이터베이스, 웹 서버 또는 기타 외부 요소 없이 테스트할 수 있습니다.
3. UI와 독립적입니다.
   1. 시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있습니다. 예를 들어 비즈니스 규칙을 변경하지 않고도 웹 UI를 콘솔 UI로 교체할 수 있습니다.
4. **DB(데이터베이스)**와 독립적입니다.
   1. Mongo, BigTable, CouchDB 등을 위해 Oracle 또는 SQL Server를 교체할 수 있습니다. 소프트웨어의 비즈니스 규칙은 데이터베이스에 바인딩되지 않습니다.
5. 외부 요소로부터 독립적입니다.
   1. 소프트웨어의 비즈니스규칙은 외부 요소와 분리됩니다.

Dependency Rule (의존성 규칙)

---

<이미지 출처: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html>

 

해당 이미지는 소프트웨어의 다양한 영역을 표시한 이미지입니다.

• 바깥쪽원에서 내부로 갈수록 소프트웨어 수준이 낮은 수준에서 높아집니다.
• 의존성 규칙은 내부만 가리킬 수 있습니다. 내부 원 계층에서 외부 원 계층의 무엇이 있는지 알 수 없습니다. 즉, 외부 원 계층에서 내부 원 계층의 의존성을 가지면 안됩니다.
• SOLID 원칙

 

 

Entities - (이미지 중 노락색 계층 참고)

---

Entities에는 모든 비즈니스 규칙을 캡슐화합니다. 메서드가 포함된 개체일 수 있고 데이터 구조 및 함수의 집합체일 수 있습니다.

해당 계층은 외부적인 것이 바뀔 때 바뀔 가능성이 가장 적은 계층입니다.

 

Use Cases - (이미지 중 빨간색 계층 참고)

---

Use Cases에는 애플리케이션별로 비즈니스 규칙이 포함되어 있습니다. Entities계층과 데이터를 주고 받는 데이터 흐름을 조정하는 계층입니다.

Use Cases 계층의 변경사항이 entities계층에 영향을 미치면 안되고, DB, UI, Common Framework에 영향을 받으면 안됩니다.

 

Interface Adapters - (이미지 중 초록색 계층 참고)

---

Interface Adapters 계층은 use cases, entities계층의 가장 편리한 형식에서 DB, Web과 같은 외부요소에 편리한 형식으로 데이터를 변환하는 계층입니다.

 

Frameworks and Drivers - (이미지 중 파란색 계층 참고)

---

가장 바깥쪽 계층으로 일반적으로, DB, Web Framework 등으로 구성됩니다.

 

 

주의점

---

🚨 주의 : 꼭 4개의 레이어 또는 이상으로 맞춰야 하지 않기 때문에 필요한 경우에 따라 레이어의 분리를 하면 됩니다. 하지만, 의존성 규칙들을 적용해야 합니다.

 

 

🧹 iOS Clean Architecture이란?

---

iOS앱을 특정 역할을 가지는 레이어(layer)로 분리하는 아키텍처패턴입니다.

클린아키텍처를 도입하면 프로젝트의 버그를 쉽게 해결하거나 특정 레이어의 기능을 변경할 수 있습니다.

<이미지 출처 : https://tech.olx.com/clean-architecture-and-mvvm-on-ios-c9d167d9f5b3>

 

📱 Presentation Layer

---

Presentation Layer는 UI , Presenter , ViewModel 로 구성됩니다.

또한, Domain Layer에 종속되어 있습니다.

 

🛜 Domain Layer (Business Logic)

---

Domain Layer는 Use case/Interactor , Entity , Repository Interface로 구성됩니다.

Domain Layer는 독립적인 Layer입니다.

다른 프로젝트내에서 재사용될 수 있습니다.

 

💿 Data Layer (Data Repositories)

---

Data Layer는 Repository Implementation , DataSource 로 구성됩니다.

Data Layer는 data source에서 원격(remote) 또는 로컬(local)로 데이터를 가져옵니다.

Domain Layer에 따라 달라질 수 있습니다.

 

 

MVVM with Clean Architecture

---

 

<이미지 출처 : https://tech.olx.com/clean-architecture-and-mvvm-on-ios-c9d167d9f5b3>

 

 

이미지를 보면, Data Layer와 Presentation Layer는 모두 Domain Layer에 종속되어 있습니다. Data Leyer에서 Domain Layer에 종속되기 위해 의존성역전을 사용합니다. 따라서 Repository Interface를 구현한 후 Data Layer에서 Repository를 구현합니다.

Presentation Layer에서 MVVM패턴을 활용합니다.

 

마치며

---

적용해보고 느낀점은 위의 글에서 말했던 장점들을 직접 느끼게 되는 것 같다.

• 실제 사용사례에서 느낀점
  • DTO를 작성할 때, quicktype.io를 사용하는데 실제 필요한 키값만 정리를 할 필요가 없이 그대로 가져온 후 Domain Layer에서 Entities를 필요한 키값만 사용하면 프로젝트내에서 2가지(DTO, Entities)를 비교해갈 수 있는 장점이 있는 것 같다.
  • UnitTest를 작성할 때, ViewModel만을 테스트하면 되기 때문에 테스트코드 작성이 수월한 것 같다.
  • View의 변경이 자유로운 것 같다. (UIKit과 SwiftUI의 이동이 수월하다.)
  • 자동으로 모듈화가 되고 추후 프레임워크로 분리한다면 더욱 편리할 것 같다.
  • 파일의 갯수가 많아 개발 속도가 더 오래걸리는 단점이 있지만, Xcode 템플릿을 활용하면 보완이 될 것 같다.
  • 원하는 파일 및 원하는 부분등을 찾기 쉬워 작업(이슈 수정, 기능추가, 코드리뷰)등이 편리할 것 같다.

아래 참고링크의 CleanCode 문서는 광범위한 소프트웨어의 CleanArchitecture를 설명하고 나머지 링크들을 참고하여 iOS앱에서 CleanArchitecture를 자세히 설명한 글들을 참고하기 좋습니다.

 

🔗 참고링크

---

• CleanCode 문서
• What is iOS clean architecture? - Medium
• MVVM with Clean Architecture Template- https://github.com/kudoleh/iOS-Clean-Architecture-MVVM
  • 관련 Medium기사

•