Clean Architecture란

소프트웨어(Software)란 제품이 출시되면 변경이 어려운 유형의 하드웨어(Hardware)와 다르게 유연한 변경과 확장이 가능하다.
그러나 시스템 아키텍처를 고려하지 않고 만든 소프트웨어는 유연한 변경과 확장이 어렵고 이는 무형임에도 하드웨어와 다를바가 없어진다고 생각한다.

이를 위해 나온것이 클린 아키텍처이며(즉, 유연한 변경과 확장이 가능하도록 설계하는 것), 클린 아키텍처는 소프트웨어를 계층으로 분리하여 시스템 구성요소들의 독립성을 강화하고 의존성을 약화하여 그 자체로 언제든 테스트 용이하게 만든다.

이는 앞서 말한 소프트웨어의 유연한 변경과 확장을 가능캐한다.

계층

Swift에서 클린 아키텍처를 적용하면 보통 3가지 레이어로 구분한다.
아래에서 말하는 컴포넌트는 각 계층 안에서 역할을 가지고 시스템을 구성하는 독립된 요소를 말한다.

Presentation Layer

사용자 인터페이스와 UI가 관련된 모든 요소를 포함하고 있다.
어플리케이션의 핵심 기능(비즈니스 로직)이 Domain Layer에 수행되고,
ViewModel은 사용자 인터페이스에 관련된 비교적 간단한 로직이 수행된다.

주요 컴포넌트: View, ViewController, ViewModel

Domain Layer

어플리케이션의 주요 정책과 핵심 로직들이 구현된다.

주요 컴포넌트: Entity, Usecase, Repository(Interface)

Entity

• 비즈니스 모델로 전사적인 핵심 업무 규칙을 캡슐화한다.
• 메소드를 가지는 객체 또는 일련의 데이터 구조와 함수의 집합일 수 있다.
• 가장 일반적이며 고수준인 규칙이 된다.

비즈니스 로직 즉 Domain Layer에서 사용되는 핵심 데이터로 보려고 한다.

이 후 나올 Data Layer에 DTO가 외부 통신에 데이터 전송만을 위한 데이터 객체라 한다면,

Entity는 이러한 DTO를 비즈니스 로직에서 사용할 수 있도록 변환한 데이터 객체라고 이해하면 편리할 것 같다.

이러한 Entity는 데이터를 조작하고 처리하는 메소드도 포함될 수 있다.
ex) 데이터 유효성 검증

UseCase

• 어플리케이션에 특화된 업무 규칙(기능, 작업 수행 로직)을 캡슐화한다.

앞서 설명한대로 ViewModel이 UI와 관련된 로직들을 처리한다면, 어플리케이션의 핵심 기능은 이 곳에서 처리된다.

Repository(Interface)

• UseCase에서 Repository Interface를 통해 데이터 접근을 요청한다.
• 특정 데이터 소스(데이터베이스, 외부 API)에 접근하기 위한 메소드들을 정의한다.

Repository는 특이하게 Interface는 Domain Layer에
구현체(Impl)은 Data Layer에 속하는데, UseCase에서는 Interface를 통해 접근하고, 실제 구현체는 실질적인 데이터소스와의 상호작용을 처리하기 때문에 이렇게 나누어지는 것 같다.

Data Layer

실제 데이터 소스와 상호작용하는 영역이다.

Mapper

• Data Layer의 DTO를 Domain Layer의 Entity로 변환시켜준다.

Repository(Impl)

• Repository의 실제 구현부로 데이터소스와의 상호작용을 하는 로직을 지닌다.

DTO

• 데이터 전송 객체로, 주로 네트워크를 통해 데이터를 전송하기 위한 객체이다.
• 비즈니스 로직을 포함하지 않는다.

DataSource

• Database
• Network
• File System