[아키텍처] Clean Architecture(클린 아키텍처)를 사용하면서(feat.DIP)

안녕하세요.

오늘은 새로운 프로젝트를 진행하면서 적용했던 클린 아키텍처에 대해서 회고해 보는 시간을 가져보려고 합니다.

클린 아키텍처에 대해서는 많은 블로그 포스팅이 존재하고 있어서 클린 아키텍처의 구조는 어떤지, 왜 사용하는지, 누가 해당 아키텍처를 소개했는지 등등 알기 쉬울 거라고 생각합니다.

해당 포스팅에는 그와 관련된 내용보다는 후기 위주니 참고 부탁드립니다.

 

---

 

클린 아키텍처?

새로운 프로젝트를 시작하기에 앞서서

iOS 개발을 담당하는 인원이 저 하나였기 때문에 어떤 식으로 설계를 해야 할지 고민이 많았습니다.

기존에는 간단한 앱들을 MVVM 디자인 패턴을 사용해서 구현해왔지만 

규모가 기존보다는 커졌기 때문에 디자인 패턴이 아닌 아키텍처가 필요했던 것 같습니다.

가장 널리 알려지기도 했고, 많은 사람들이 사용하고 있는 클린 아키텍처를 선택하게 되었는데

아무래도

각 유지보수 측면에서 큰 장점이 있는것이 선택의 주된 이유였습니다.

즉, 혼자 개발한다는 점도 있지만 초기 컨셉이나 요구되는 비즈니스 로직이 언제든지 변경될 수 있다는 점을 감안해서

가장 적합한 아키텍처가 될 거라고 생각했습니다.

 

이거 하나면 알면 클린 아키텍처 다 아는걸지도?

클린 아키텍처에 대해서 공부하면서

가장 도움이 되었던 것은 아래의 이미지였습니다.

클린 아키텍처를 공부하다 보면수 많은 원들과 마주하게 되는데

그 수많은 원들도 이해에 도움을 주지만

저는 이 네모네모들이 이해하기에는 더 수월했던 것 같습니다.

UI layer와 Presenter layer가 분리되어 있는데 이는 기존의 Present layer를 세분화해서 넣어 뒀다고 생각하면 편할 것 같습니다. 

익히 알고 있듯이 View의 경우, ViewModel에 의존성을 가지고 있습니다. 마찬가지로 ViewModel의 경우, 비즈니스 로직을 담당하는 Domain layer의 Use Case에 의존성을 가지고 있습니다. ViewModel은 Use Case에 뷰에 필요한 데이터를 요청하고 받아온 데이터를 가공해 View에 Binding 되는 것입니다. 위의 이미지에서 보이는 Data flow는 이 내용을 말합니다.

반대방향에서 시작해 본다면  Data layer의 Repository들은 API나 DB를 통해서(요청) 받아온 데이터들을 Use Case에서 조합하여 ViewModel에 전달하게 됩니다. 

여기서 Use Case가 Repository에 의존성을 가지고 있는 것이 아닌가 하는 의문이 생겼었습니다. 

Use Case는 repository를 가지고 이를 통해 데이터를 요청하고 받아오기 때문에 이러한 의문이 생겼는데 위의 이미지처럼 DIP(Dependency Inversion Principple)이 적용되기 때문에 의존성이 역전됩니다.

간단한 예시를 들어보면 다음과 같습니다.

class Person {

    let car = Tesla()

    init() {
    
    }
}

class Tesla {

}


class Hyundai {

}

 

위와 같이 Person는 Tesla에 의존하고 있게 됩니다. 즉, Tesla 인스턴스를 Person에서 직접 생성하기 때문입니다.

protocol Vehicle {
	func start()
}

class Person {
	let car: Vehicle

    init(car: Vehicle) {
    	self.car = car
    }
    
    func start() {
    	car.start()
    }
}

class Tesla: Vehicle {
    func start() {
    
    }
}


class Hyundai: Vehicle {
    func start() {
    
    }
}

 

위의 코드를 살펴보면 의존성을 외부로부터 전달받아 사용하고 있으며 프로토콜을 이용해 car에 구현체인 Tesla나 Hyundai가 아닌 Vehicle 프로토콜 타입을 주입시킨 것을 확인할 수 있습니다.

이렇게 되면 DIP 원칙에 따라 추상화된 것이 구체적인 것에 의존하지 않고 반대인 구체적인 것이 추상화된 것에 의존할 수 있게 되어 의존성 역전이 발생하게 됩니다. 즉, 구체적인 클래스(Tesla, Hyundai)와의 의존관계가 아닌 프로토콜(Vehicle)과 관계를 맺음으로써 느슨한 결합이 만들어지게 되고 클린 아키텍처의 특성인 관심사의 분리를 지킬 수 있게 됩니다.

 

폴더 구조를 만들어보자

막상 시작하려고 하니 뭐부터 해야 할지 모르겠어서

가장 먼저 Github에 들어가 좋은 레포들을 탐색해 봤었습니다.

평가가 좋은 레포들 중에서 아래의 레포가 가장 유명하기도 해서 해당 프로젝트를 자세하게 들여다봤었습니다.

해당 레포를 보면서 전체적인 클린 아키텍처의 구조를 만들어가는데 정말 많은 도움이 되었던 것 같습니다.

GitHub - kudoleh/iOS-Clean-Architecture-MVVM: Template iOS app using Clean Architecture and MVVM. Includes DIContainer, FlowCoor

일단,

처음에는 Kudoleh님과 비슷한 폴더 구조를 만들어 두고 시작했었습니다.

크게 5개의 폴더를 만들어 사용했는데 아래와 같습니다.

Application: plist 파일이나 환경변수와 같은 파일을 보관해서 사용했었는데 Kudoleh님은 의존성 관련 파일이나, 앱의 전체적인 Appearance 등 Base가 되는 파일들을 이곳에 두고 사용했었습니다. 추후에 Swinject와 같은 라이브러리를 도입하게 된다면 그와 관련된 파일을 추가해봐야 할 것 같습니다.

Domain: 비즈니스 로직을 담당하는 Use Case가 들어있는 폴더입니다. 추가적으로 Repository Interface와 entities들이 이곳에 같이 있습니다. Repository Interface가 이 폴더에 있는 이유는 클린 아키텍처의 구조상 관심사의 분리와 종속성 때문입니다. 도메인 계층의 경우, 외부 계층(Data layer, Present layer)에 의존해서는 안되기 때문에 인터페이스를 이곳에 배치함으로써 실제로 데이터 소스 구현에 의존하지 않고 정의함으로써 해당 속성을 준수할 수 있게 됩니다.

Presentation: 이름 그대로 View와 관련된 즉, 화면에 보이는 것들을 넣은 폴더입니다. ViewModel의 경우에도 Presentation layer에 포함되기 때문에 해당 폴더에 배치했습니다. 

Data: Network와 관련된 파일 그리고 Repository들이 들어있는 폴더입니다. 현재 프로젝트에서는 CoreData나 realm가 같은 로컬 스토리지는 사용하지 않고 API를 통해 데이터를 받아와 사용해 해당 파일들이 배치되어 있습니다.

Infrastructure: Network의 Base 파일들이 들어있습니다. 저의 경우, Moya 라이브러리를 사용했는데 Target 파일들과 Moya plugin들, Moya intercepter, APIError 등을 정의한 파일을 배치했습니다.

처음에는 어떤 게 어디에 들어가야 할지 횡설수설 많이 했지만 

언젠가부터는 자연스럽게 파일들을 배치할 수 있게 되었던 것 같습니다. 

시간이 되면 전체적으로 다시 한번 정리해 볼 필요도 있을 것 같네요.

 

아직 프로젝트는 끝나지 않았지만..

구조도 잡고 실제로 사용하면서 느꼈던 장점은 재사용성과 유지보수의 용이성이었습니다.

어떠한 기능이나 비즈니스 로직이 추가되더라도

간편하게 구현할 수 있었던 게 가장 큰 이점이 아니었나 생각이 드네요.

예를 들어서

비즈니스 로직이 추가된다면 해당 비즈니스 로직을 요구하는 ViewModel의 Use Case를 파악하고

Repository Interface에 해당 요구사항을 작성했습니다. 그런 다음 Repository에 요구사항을 구현하고 이를 Use Case에

서 ViewModel에 전달하고, 이를 View에 바인딩하면 됐었습니다. 

다시 생각해 보면 각 계층의, 클래스의 역할이 확실하기 때문에

작업을 진행할 때에 있어서 스스로도 명확하게 구현할 수 있었던 것 같습니다.

 

---

 

오늘은 대략적인 Clean Architecture 후기를 남겨봤습니다.

그럼 이만 👋🏻 👋🏻