클린 아키텍쳐 톺아보기 [1 / 3]

[seungchan2]

로버튼 C. 마틴 행님이 만든 .. 클린 아키텍쳐에 대해 살펴보겠음

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. 비즈니스 로직은 외부 세계

이런 다양한 아키텍쳐를 단일 아이디어로 통합하길 원했고,

그러면서 나온 것이 클린 아키텍쳐임

The Dependency Rule

outer circles - mechanisms
inner circles - 정책

클린 아키텍쳐를 작동시키는 우선적인 규칙은 Dependency Rule임

Dependency Rule 

• 소스코드 종속성은 안쪽으로만 향할 수 있음
• inner circles 안에 있는 것들은 outer circles에 대해 아무것도 알 수 없음
• 특히, outer circles에 선언된 이름은 inner circles에서 언급해서는 안 됨 (함수, 클래스 등등)

outer circles이 inner circles에 영향 안미쳤으면 좋겠음!

Entities

Entity는 "Enterprise wide business rules"을 캡슐화하는 것임

외부 변화가 있을 때 변경될 가능성이 가장 적은 것들

일반적으로 가장 높은 수준의 규칙을 캡슐화 함

앞으로 영화 검색 앱을 예시로 들어서 설명을 할 거임

영화 검색 앱에서 Entity가 �뭘 것 같음?

영화 검색 앱에서는 뭐가 아무리 바뀌든간에 영화 검색 앱이니까 무조건 영화에 대한 정보를 보여줘야 함

따라서 데이터 구조 Movie가 Entity가 되는 것임

import Foundation

struct Movie: Equatable, Identifiable {
    typealias Identifier = String
    enum Genre {
        case adventure
        case scienceFiction
    }
    let id: Identifier
    let title: String?
    let genre: Genre?
    let posterPath: String?
    let overview: String?
    let releaseDate: Date?
}

struct MoviesPage: Equatable {
    let page: Int
    let totalPages: Int
    let movies: [Movie]
}

Use Cases

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

Use cases circle은 시스템의 모든 Use cases를 캡슐화하고 구현함

Use cases는 Entity와의 데이터 흐름을 조정하고

해당 Entity가 Use cases의 목표를 달성하도록 "지시"하는 역할을 함

그렇다면 영화 검색 앱에서의 Use Cases는 뭐겠음?

영화 검색하는 부분일 것임

Use cases는 사용자에게 보여줄 출력을 위해

해당 출력을 생성하기 위한 처리 단계를 기술하는 곳이라고 보면 됨

이 Use cases를 Use cases Interactor라고도 함

Entities는 이 Use cases에 대해 전혀 알지 못하지만 Use cases는 Entities를 알고 있음

하지만 이 Use cases 계층의 변경이 Entities에 영향을 미치면 안 됨

또한 Use cases가 DB, UI 같은 외부 환경의 변경으로 인해 영향을 받지 않아야 함

왜냐면 그냥 정말 단순히 Use cases이기 때문에 데이터가 어디에 저장되어있든 외부 프레임워크가 바뀌든 상관없는 것임

하지만! 앱 전체의 작동 방식 변경(?)은 Use cases에 영향을 미칠 수 있음

사용자의 시나리오가 바뀌는 것이니까

Interface Adapters

Controllers, Gateways, Presenters

이들을 Interface Adapters라고 함

그림에서 볼 수 있듯이, 이 Interface adapter에 (View)Controllers, Gateways, Presenters가 속함

이 계층을 Interface Adapters라고도 하고, Presentation Layer라고도 함
 
이 계층에 데이터가 딱 들어오면 Entities, Use cases에 가장 편리한 format에서

DB 등과 같은 외부 프레임워크에 가장 편리한 format으로 변환되는 곳

즉, DB는 딱 이 원까지만 알아야 함

Use cases, Entities에 있는 코드들은 DB에 대해 아는것이 1도 없어야 함

Frameworks and Drivers.

이 계층에는 일반적으로 DB, 프레임워크 같은 것들로 구성이 됨
 
그러니까 Dependency Rule의 방향을 보면, 
DB -> Adapter -> Use Cases -> Entities로 되는 것을 볼 수 있죠!

Only Four Circles?

현재는 원의 개수가 4개인데 꼭 4개여야만 하나?

당연히 아님 원이 몇개든 Dependency Rule만 안쪽을 향하면 됨

안쪽으로 갈수록 추상화 수준이 증가하면 됨

Crossing boundaries.

분홍색 선을 보면 Controller에서 시작해서 Use Case를 거쳐 Presenter에서 실행되는 구조임

그럼 결국 Use case가 Presenter를 호출 할 수도 있음.

여기서 모순이 Dependency Rule의 모순이 새김

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

Use case가 Presenter를 호출한다는건

Use case가 Presenter에 대해서 안다는 소리가 됨

• inner circles 안에 있는 것들은 outer circles에 대해 아무것도 알 수 없음
• 특히, outer circles에 선언된 이름은 inner circles에서 언급해서는 안 됨 (함수, 클래스 등등)

Output Port라는 "인터페이스"를 둠

그래서 Use case는 이 Output port에 있는 인터페이스를 호출함

그리고 Presenter는 이 Output port 인터페이스를 구현함

직접 Presenter의 구현체에 접근을 안하고 인터페이스를 통해 접근한다는 것이 가장 중요함

제드님 티스토리 보고 공부했음! 내용은 동일. .