iOS Clean Architecture 정리 (코드 분석)

iOS Clean Architecture 정리 (코드 분석)

 

iOS CleanArchtecture Example + MVVM 으로 깃헙에서 유명한 프로젝트를 분석해보고자 함.

 

히스토리

• 2022-09-23: 클린 아키텍처 스터디 (깃헙 프로젝트 분석)
• 2024-12-09: 포스팅 글 깔끔하게 정리

목차

• [iOS Clean Architecture (MVVM)](https://rldd.tistory.com/497)
• [iOS Clean Architecture (실습)](https://rldd.tistory.com/498)

 

배경

아래의 다섯가지 개념을 단일 아이디어로 통일하기 원했고, 따라서 소개한 아아디어가 클린 아키텍처

• Independent of Frameworks: 아키텍쳐는 소프트웨어 라이브러리의 존재에 의존하지 않음.
• Testable: 비즈니스 로직은 UI, DB, 웹 서버 또는 기타 외부 요소 없이 테스트 할 수 있음.
• Independent of UI: UI는 시스템을 변경하지 않고도 쉽게 변경 가능 (ex. 비즈니스 로직을 바꾸지 않고 웹 UI를 콘솔 UI로 변경 가능)
• Independent of Database: 비즈니스 로직이 DB에 바인딩 되지 않음
• Independent of any external agency: 비즈니스 로직은 외부 세계(outside world)에 영향을 받지 않음.

 

클린 아키텍쳐 다이어그램.

 

 

The Dependency Rule

각각의 원은 소프트웨어의 영역을 나타냄.

• 외부 원- mechanisms
• 내부 원 - policy

예전에 OS 교수님께서 말씀해주신 설명 중에 policy와 mechanism에 대한 비유

• policy는 수능으로 치면 수시, 정시임.
• mechnism은 수시 내에서 학생부종합, 성적우수, 논술 등 이렇게 나뉘는 것을 말함.

클린 아키텍처를 작동시키는 가장 우선적인 규칙은 Dependency Rule.

• 소스코드 종속성은 안쪽으로만 향할 수 있음.
• inner circles 안에 있는 것들은 outer circles에 대해 아무것도 알 수 없음.
• 특히, outer circles에 선언된 이름은 inner circles에서 언급되어서는 안된다. (함수, 클래스 등)
• 한마디로 정리하자면 외부 원이 내부 원에 영향을 미치지 않기를 바람.

 

단면도

 

 

예제 분석하기

클린 아키텍처를 공부하고자 먼저 깃헙에서 유명하다는 코드를 분석해보고자 함.

• https://github.com/kudoleh/iOS-Clean-Architecture-MVVM

 

클린아키텍처 그룹 구조

 

일반적으로 Domain, Presentation, Data 레이어로 구성 존재

•  Domain 레이어에는 Entity와 Use Cases에 대한 부분이 위치
• Presentation 레이어에는 Interface Adapters(Presentation Layer) 부분이 위치
• Data 레이어에는 Frameworks and Driver 부분이 위치

 

클린 아키텍처에서의 코드 흐름

클린아키텍처 설명

Domain Layer 살펴보기

일반적으로 엔티티, UseCase, 인터페이스가 존재

도메인 그룹 구조

Entity

엔티티라하면 Domain에서 사용하는 데이터 구조로 비즈니스 로직에서의 모델로 활용

 

Entity

 

UseCases

UseCase는 시스템 동작을 사용자 입장에서 표현한 시나리오

• 소프트웨어 공학 등의 수업에서 일컫는 용어 참고
• 시스템의 모든 유즈케이스를 캡슐화하여 구현
• 엔티티와 데이터의 흐름을 조정하고 사용자 혹은 시스템 행동에 따른 UseCase의 목표를 달성하도록 지시하는 역할
• RIBs나 VIPER의 Interactor 혹은 Worker의 개념과 닮음
• 일반적으로 유즈케이스는 하나의 역할만 담당
• DIP 개념을 통해 의존성 관리를 통한 생상선 향상 도모

코드샘플 2개를 통해 구현의 차이를 비교해보고자 함.

• execute 함수에서 직접 결과를 반환
• 클로저를 Init으로 받아 결과 전달
• 두개의 방식은 각각의 장단점이 있어서, 내가 구현하는 구조에 따라 적절하게 처리하기

1. 함수 컴플리션을 통해 값 전달 2. init으로 전달된 클로저 프로퍼티를 저장해 값 전달

 

 

Presentation Layer 살펴보기

일반적으로 ViewContoller와 ViewModel이 위치

• 뷰와 뷰모델은 언제나 수동적인 존재로 그리는 역할만을 담당
• 해당 레이어에서 Coordinator가 위치

프레젠테이션 레이어 그룹 구조

 

Frameworks and Drivers

외부의존성이나 데이터베이스 등은 일반적으로 하위레벨에 위치

 

그렇다면 반드시 클린 아키텍처를 따라야 하는가?

클린 아키텍처는 디펜던시 룰을 지키며 객체지향적인 설계를 하라는 것이지 반드시 모든 레이어가 다 존재하거나 추가적으로 몇몇 레이어를 만들어서 사용해도 됨

 

안드로이드 같은 경우에는 공식 아키텍처에서 도메인 레이어가 단순히 래핑용인 경우가 많아 옵셔널로 명시되어 있음.

 

Crossing boundaries

의존성 역전 활용하여 소스코드의 의존성과 런타임 의존성을 구분

• 빌드 시간 개선, 추상화 등 다양한 이점 존재

Interface