[iOS/Design Pattern] Clean Architecture를 알아보자.

클린 아키텍처?

클린아키텍처란?

 클린 아키텍처는 소프트웨어 설계 원칙으로, 로버트 C. 마틴이 제안한 개념이다. 클린 아키텍처의 주요 목표는 아래와 같다.

 

1. 프레임워크 독립성 : 시스템이 특정 프레임워크에 종속되지 않도록 한다.

➡️ 처음에는 UIKit을 사용했지만, SwiftUI로 전환해야 할 상황이 생겼다. 

비즈니스 로직을 UIKit과 독립적인 별도의 모듈로 구현한다. 이렇게 하면 나중에 SwiftUI로 전환하고자 할 때, UI레이어만 변경하면 되고 핵심 비즈니스 로직은 그대로 사용할 수 있다.

 

2. 테스트 용이성 : 비즈니스 로직을 외부 요소 없이 테스트할 수 있게 한다.

➡️ '장바구니에 책 추가하기' 기능을 구현한다고 가정하자. 이 기능을 순수한 비즈니스 로직으로 구현하여, 필요한 외부 의존성(데이터베이스 등)은 인터페이스를 통해 주입받는다. 이렇게 하면 실제 데이터베이스 없이도 mock 객체를 사용하여 이 기능을 쉽게 단위 테스트할 수 있다.

 

3. UI 독립성 : UI를 변경해도 시스템의 나머지 부분에 영향을 주지 않는다.

➡️ '책 목록 보기' 화면을 생각해보자. 책 목록 데이터를 관리하는 로직을 UI와 분리된 별도의 usecase나 viewModel로 구현하여, UI를 테이블 뷰에서 컬렉션 뷰로 변경하거나, 심지어 완전히 다른 UI 프레임워크로 전환해도 책 목록을 관리하는 핵심 로직은 변경할 필요가 없다.

 

4. 데이터베이스 독립성 : 비즈니스 규칙이 데이터베이스에 의존하지 않는다.

➡️ '사용자의 주문 내역' 기능을 구현한다고 가정하자. 주문 데이터 접근을 추상화한 인터페이스(ex: OrderRepository)를 정의하고, 비즈니스 로직은 이 인터페이스만 사용한다. 이렇게 하면 처음에 CoreData를 사용하다가 나중에 Realm으로 전환하고 싶을 때, OrderRepository의 구현만 변경하면 되고 비즈니스 로직은 그대로 유지할 수 있다.

 

5. 외부 요소 독립성 : 비즈니스 로직이 외부 인터페이스나 서비스에 대해 알 필요가 없다. 

➡️ '책 정보 가져오기' 기능을 외부 API를 통해 구현한다고 가정하자. API 호출과 응답 처리를 별도의 데이터 소스 레이어에 캡슐화 하고, 비즈니스 로직은 앱 내부에 정의한 '책'모델만 다룬다. 이렇게 하면 나중에 다른 API로 전환하거나 API의 응답 형식이 변경되어도, 데이터 소스 레이어만 수정하면 되고 비즈니스 로직은 영향을 받지 않는다.

 

✅ SW에서 맡은 역할에 따라 레이어를 나눈 후, 완전히 분리시켜 의존성을 낮추는 것이 목표이다.

 

관심사의 분리

 관심사의 분리란 프로그램 내부에서 관심있는 것들끼리 모아서 분리하는 것이다. 여기서 말하는 관심사는 프로그램 내부에서 해결 또는 처리하려는 목표라고 생각하면 된다.

 

✅ 관심사의 분리는 특정 관심사를 기준으로 프로그램을 분리하고, 각 부분은 하나의 관심사를 해결한다.

 

구성요소

 

✔️Entity

비즈니스 로직과 규칙을 포함하는 핵심 객체이다. 변경될 가능성이 가장 적은 부분이다.

➡️ 한 회사가 도서 검색 서비스를 제공할 때, 검색 될 도서 리스트는 서비스의 '근본'이자 원천이 되는 데이터이고, 이 데이터를 처리하는 비즈니스 로직이 있을 것이다. 이 둘을 합쳐서 Domain이라 부르는데, 클린 아키텍처에서는 Entity와 UseCase가 이 Domain에 해당한다. Entity는 외부에서 무엇이 변경되더라도 절대 바뀌지 않는다.

 

✔️UseCase

애플리케이션의 비즈니스 로직을 포함한다.

➡️ 도서 검색 서비스에서, 검색 기능이 비즈니스 로직이 될 수 있다.

 

✔️Interface Adapters

Controller, GateWays, Presenter을 포함한다.

➡️ 데이터가 Entity나 UseCase에서 사용하기 쉬운 형태에서, DB와 같은 외부 프레임워크에 사용하기 쉬운 형태로 변환되는 곳이다. MVVM의 ViewModel이 여기에 포함된다. 이 계층의 안쪽 계층들은 DB에 관해서는 아무 것도 몰라야한다. 즉, DB 관련 부분은 이 계층에 제한되어있어야한다. 

 

✔️ Frameworks and Drivers

DB, Web, Device, UI, External Interfaces를 포함한다. 변경될 가능성이 비교적 큰 부분이다.

➡️ UI를 담당하는 View나 프레임워크로 구성된다. 이 계층에서는 안쪽 계층과 통신할 코드 외에는 별다른 코드가 없다. 

 

의존 규칙

 클린 아키텍처의 의존 규칙은 위 그림과 같이 안쪽 계층을 향해서만 의존할 수 있다. 안쪽의 계층은 바깥쪽의 계층을 전혀 모른다. 안쪽의 계층은 바깥쪽의 어떤 것도 참조해서는 안된다. 

 

 위의 그림은 Controller ➡️ UseCase ➡️ Presenter의 흐름이다. 여기서 의존성은 의존 규칙에 따라 모두 안쪽 계층을 향하고 있다. 흐름과 의존의 방향이 역방향으로의 구현은 DIP로 해결하는 경우가 많다.

 

계층의 분리

 모바일 설계에서 클린 아키텍처를 적용하기 위한 방법 중 하나로, 3Layer 형태로 사용한다.

 

1. Domain Layer (도메인 계층) : 앱의 핵심 비즈니스 로직을 포함하는 계층

Entity와 UseCase, Repository Interface를 포함한다.

✔️ Repository Interface : 도메인 계층에서 사용자의 요청을 처리하다보면, 데이터 계층에 의존성을 갖는 의존성 역전 현상이 발생하게 된다. 그래서 Repository Interface를 정의하고, 구현은 데이터 계층에서 하게하여 의존성 역전 현상을 해결할 수 있다.

 

2. Presentation Layer (프레젠테이션 계층) : 사용자 인터페이스와 관련 된 로직을 담당하는 계층

View, Presenters를 포함한다.

✔️ Presenters : MVP/VIPER라면 Presenter, MVVM이라면 ViewModel과 같은 역할

 

3. Data Layer (데이터 계층) : 데이터의 저장, 검색, 외부 API와의 통신을 담당하는 계층

DB, API, Repository를 포함한다.

✔️ Repository : 데이터를 가져오고 저장하기 위한 객체

✔️ DTO : 데이터 소스에서 사용되는 데이터를 정의한 모델로, REST API의 요청/응답을 위한 JSON이나 로컬 DB에 저장하기 위한 타입들을 일컫는다.

 

 

✅ 3Layer에서는 프레젠테이션 계층과 데이터 계층이 도메인 계층을 향하도록 의존성 규칙이 지켜져야한다.

 

레퍼런스

https://velog.io/@yoosa3004/iOS-CleanArchitecture-톺아보기

https://sunny-maneg.tistory.com/entry/iOS-설계에서의-Clean-Architecture