Clean Architecture Swift #1

Clean Architecture Swift #1

 

 

1. Independent of Frameworks: 아키텍쳐는 소프트 웨어 라이브러리의 존재에 의존하지 않음.

2. Testable: 비즈니스 로직은 UI, DB, 웹 서버 또는 기타 외부 요소 없이 테스트 할 수 있음.

3. Independent of UI: UI는 시스템을 변경하지 않고도 쉽게 변경 가능 (ex. 비즈니스 로직을 바꾸지 않고 웹 UI를 콘솔 UI로 변경 가능)

4. Independent of Database: 비즈니스 로직이 DB에 바인딩 되지 않음

5. Independent of any external agency: 비즈니스 로직은 외부 세계(outside world)에 영향을 받지 않음.

 

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

 

 

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

 

 

The Dependency Rule

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

 

outer circles- mechanisms

inner circles - policy

 

[ * policy와 mechanism에 대한 비유 ] 

예전에 운영체제 수업에서 교수님께서 해주신 말씀인데

 - policy는 수능으로 치면 수시, 정시임.

 - mechnism은 수시 내에서 학생부종합, 성적우수, 논술 등 이렇게 나뉘는 것을 말함.

 

 

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

 

 

The Dependency Rule

 - 소스코드 종속성은 안쪽으로만 향할 수 있음.

 - inner circles 안에 있는 것들은 outer circles에 대해 아무것도 알 수 없음.

 - 특히, outer circles에 선언된 이름은 inner circles에서 언급되어서는 안된다. (함수, 클래스 등)

 

 

그러니까 정리하자면 outer circlesdl inner circles에 영향을 미치지 않기를 바람.

 

원을 파이 조각처럼 딱 !

 

 

예제 분석하기

 

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

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

 

 

위의 코드를 통해 예제를 분석해봅시다. 

 

프로젝트 예제 파일

 

우선 시작하기에 앞서, 

 

원의 가운데를 1번이라고 부른다면,

 - Domain 폴더에는 Entity와 Use Cases에 대한 부분이 들어 있습니다. (원 1번, 2번) - Domain layer

 - Presentation 폴더에는 Interface Adapters(Presentation Layer) 부분이 들어 있습니다. (원 3번) - Presentation layer

 - Data 폴더 부분에는 Frameworks and Driver 부분이 들어 있습니다. (원 4번) - Data layer

 

 

 

 

Domain쪽 코드 파일들

1. Entity

 

Entity

 

Entity의 경우에는 모델과 닮았습니다.

"일반적으로 가장 높은 수준의 규칙"

"Movie"라는 데이터 구조가 엔티티입니다.

간단하게 생각하자면 엔티티는 데이터 구조 및 함수의 집합이라고 생각할 수 있습니다.

그냥 모델이라고 생각하시면 훨씬 쉽습니다.

 

 

2. Use Cases

다음으로는 Use cases입니다. 

소프트웨어 공학 시간이나, HCI, UX 등 여러 수업에서 문서를 통해 Use Cases를 많이 작성했었는데, 여기서 이렇게 다시 보니 정말 반갑네요!

 

UseCase의 경우에는 

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

Use cases circle은 시스템의 모든 Use ases를 캡슐화하고 구현합니다.

즉, 엔티티와의 데이터 흐름을 조정하고, 해당 엔티티가 Use cases 목표를 달성하도록 "지시"하는 역할을 수행합니다.

 

 

자 문서로는 수도 없이 많이 작업해 보았습니다. 그렇다면 코드로는 어떻게 될까요?

 

코드를 한번 봅시다.

 

Use Cases

 

 

1. init에 Repository라는 것이 보인다.

2. excute라는 메소드가 구현되어 있다.

3. movie fetch는 Repository의 fetch에서 구현되어 있다.

 

자 하나하나 살펴봅시다.

Repositroy라는 개념은 아직 설명되진 않았습니다. 

Domain의 폴더 구조에서 볼 수 있듯이 Interfaces에 Repositories이 구현된 것을 확인할 수 있습니다.

여기서 사용되는 Repositories는 fetch 등 네트워크와 연결되는 부분에 Repository라는 것을 사용한 것을 확인했습니다.

 

Repositories 부분은 Interfaces로 글의 하단에 Cross Boundaries에서 더 구체적으로 설명합니다.

Repository에 대한 모식도

 

해당 예제에서는 Use Case를 작성하는 더 제네릭한 방법에 대한 옵션도 제공해주고 있습니다.

 

Use cases의 경우에는 Use cases Interactor라고도 불립니다.

Entities는 이 Use cases에 대해서 전혀 알지 못합니다. 

그러나 Use cases는 Entities를 알고 있습니다.

또한 여기서 중요한 점이 Use cases는 DB, UI 같은 외부 환경의 변경으로 인해 영향을받지 않아야 한다고 합니다.

 

사용자의 시나리오가 바뀌는 경우에는 Use case도 변경될 수 있으나, 외부 프레임워크가 바뀌거나 데이터가 저장된 위치가 바뀐다고 해서 영향을 받으면 안됩니다.

 

 

 

Interface Adapters(Presentation Layer)

presentation layer

구성파일들

 

일단 여기부터 살짝 짚고 넘어가자면, 다른 분들 코드를 정말 많이 보곤 하는데 Scene에 대한 부분입니다.

 

 

Controller, Gateways, Presenters가 적힌 circle입니다.

 

여기 계층에 진입한 순간 엔티티, 유즈 케이스에서 가장 편리한 format에서 DB 등과 같은 외부 프레임워크에 가장 편리한 format으로 변환되는 곳입니다. 

즉, DB는 딱 이 원까지만 알아야 합니다.

Use cases와 Entities에 있는 코드들은 DB에 대해서 알면 안됩니다.

 

 

Frameworks and Drivers

Drivers라고 하니까 Rx의 Driver가 생각나면서 친숙한 느낌이 드는 것 같습니다.

 

여기 레이어는 DB나 Framework, UI 등으로 구성됩니다.

 

Dependency Rule의 방향을 보면

DB -> Adapter -> Use Cases -> Entities로 되는 것을 확인할 수 있습니다.

 

 

Only Four Circles?

꼭 4개의 원만 있어야 하는건 아니라고 합니다.

그저 안쪽으로 갈수록 추상화 수준이 증가하고 원이 몇개든 Dependency Rule만 안으로 향하면 됩니다.

 

 

Crossing boundaries

 

Interface

다이어그램의 우하단을 보면 원 경계를 교차하는 방법에 대한 

Controller에서 시작해서 Use Case를 거쳐 Persenter에서 실행되는 Flow에 대한 모식도를 보여주고 있어.

 

Controller가 Presneter를 호출하기 위해서는

Controller -> Use Cases -> [?] ...

Use Cases가 Presenter에 대해서 알아야 하는데 이를 Interface를 두어서 처리하고 있다.

Interface의 경우에는 코드를 살펴보니까 Repository로 구현되어 있어서 이게 그 역할을 하고 있음!

 

[ * 여기서 UML 짚고 넘어가기 ]

소프트웨어 공학 수업에서 열심히 익힌 개념이 이렇게 또 보이니까 정말 반갑다!

소프트웨어 공학을 잘 모르는 사람을 위해서 바로 아래 Class Diagram에 대한 링크를 걸어두었음!

 

검은 화살표의 경우에는 has a로 해석하고, 흰 화살표의 경우에는 is a로 해석할 수 있다.

즉, Controller가 Use Case input port에 대한 프로퍼티를 들고있고,

Use Case Interactor(Repository)는 input을 상속받으면서, Output에 대한 프로퍼티를 들고 있다.

그리고 Presneter는 Output을 상속받아서 사용할 수 있다.

 

 

 

https://rldd.tistory.com/365?category=1036241 

[Swift] Class Diagram + 스터디

 

 

 

 

(참고)

https://zeddios.tistory.com/1065

Clean Architecture