[iOS] Clean Architecture 파헤치기

안녕하세요.
오늘은 Clean Architecture에 대해 알아보겠습니다.

Clean Architecture 란?

옛날 소프트웨어를 설계할 때, 많은 부분 하드웨어의 설계 방식을 많이 가져왔다고 합니다.

하지만, 하드웨어와 소프트웨어의 가장 큰 차이점은 하드웨어는 한번 설계할 때 완벽히 설계하여 제품 출시 이후 오점이 없어야 합니다. 오점이 있다 하더라도, 이는 수정하기가 힘들죠.
하지만, 소프트웨어는 버그가 생기면, 수정하여 다시 출시할 수 있고, 새로운 기능이 필요하다 생각되면, 추가하여 다시 출시할 수 있습니다.

정리하면, 하드웨어는 설계 단계부터 완벽해야 하지만, 소프트웨어는 언제든 확장, 수정이 될 수 있도록 유연한 설계가 필요합니다.

유연한 소프트웨어 설계를 위해 Clean Architecture와 같은 Pattern이 생겨난 것입니다.

특징

Clean Architecture는,

아래 이미지와 같이 애플리케이션에 계층을 두어 관리합니다.

(이미지 출처: https://k-elon.tistory.com/38)

1. 위 그림의 1번 계층은 UIKit 같은 Framework와 Data가 포함됩니다. Data에는 Network + DB 관련 로직들이 위치합니다.
2. 2번 계층엔 View, ViewController, ViewModel, Coordinator 등 화면 관련 객체들이 해당 계층에 속해있습니다.
3. 3번과 4번을 통틀어 Domain이라고 표현합니다. 해당 계층엔 데이터 Model, UseCase 등 프로젝트에 코어 한 로직들이 위치합니다. UseCase엔 흔히 비즈니스 로직이라고 하는 프로젝트에 핵심이 되는 로직이 포함되게 되고, 저는 주로 Data 영역과 연결되는 로직들을 UseCase에 구현합니다.

Clean Architecture의 가장 큰 특징은 계층 간 의존성은 무조건 밖에서 안으로만 의존 관계를 가져야 합니다.

즉, 3, 4번 같은 안쪽에 있는 계층은 다른 계층과 의존성이 생기면 안 됩니다.

이유는 안쪽 계층은 서비스와 연관되어 있는 로직이기 때문에 변경이 자주 발생하지 않습니다.
하지만, 1, 2번 같은 경우 화면 또는 DB, API 관련 로직이기 때문에 서비스 중에도 자주 변경될 수 있습니다.
때문에 안쪽 계층이 외부 계층과 의존성이 생기면, 외부 계층이 변경되었을 때, 안쪽 계층에도 영향이 가기 때문입니다.

의존성과 데이터 흐름

계층간 의존성 관계를 좀더 자세히 살펴 보도록 하겠습니다.

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

위 그림 처럼, Domain은 다른 계층과 의존성없이 독립되고, Presentation과 Data만 Domain에 의존성을 가지도록 디자인 해야합니다.

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

위 그림은 Clean Architecture를 도입한 프로젝트의 기본적인 데이터 흐름입니다.

사용자가 화면을 터치하는 등 액션을 발생시키면, ViewModel이 UseCase에게 액션에 대한 Output을 요청하고, 요청을 받은 UseCase는 Data 영역에 해당하는 DB 또는 Network에서 Output에 해당하는 Data를 가져오게 됩니다.

Data를 받은 UseCase는 Data를 해당 서비스에 사용되는 Model로 가공하여 ViewModel에게 반환하고, ViewModel은 전달받은 Model을 화면에 표시될 수 있는 타입으로 가공하여 화면에 표시하게 됩니다.

Domain이 다른 계층과 독립되면서, 위와 같이 데이터를 전달해야 하기 때문에 Swift에선 Protocol을 이용하여 계층 간 의존성 역전을 시켜 의존성을 분리시킵니다.

장단점

마지막으로, Clean Architecture를 도입했을 때 장단점에 대해 정리해 보겠습니다.

장점

1. 의존성이 분리되어 있기 때문에 프로젝트를 확장, 수정 그리고 테스트가 용이하다.
2. 기능별 코드 분리가 용이하다. -> 응집도 향상
3. 협업 능력이 향상될 수 있다.
4. ViewControler 또는 ViewModel에 로직이 집중되는 것을 방지할 수 있다.

단점

1. 초기 개발 단계에 작업량이 많다.
2. 개념이 어렵고, 개인마다 계층 별로 코드를 분리하는 기준이 달라 팀원간 확실한 기준이 없으면, 혼돈을 줄 수 있다.

마무리

Clean Architecture를 토이 프로젝트에 적용해 보며 느낀 가장 큰 이점은 테스트인 것 같습니다. 비즈니스 로직을 따로 테스트할 수 있어 핵심적인 기능의 오류를 찾기가 쉬웠고, 의존성이 분리되어 있어 TestDouble 객체를 이용하여 쉽고, 독립된 테스트가 가능했습니다.

초기 개발 단계에서 작업량은 많지만, 계속 유지 보수가 이뤄지는 프로젝트라면, 선택이 아닌 필수인 것 같습니다.