[실천편: 안쪽의 원 2개] iOS로 VIPER과 Clean Architecture 원의 안쪽에서 만듭니다.

저번 보도의 후속 VIPER Clean Architecture의 실천편.
이 글은 심지어 안쪽의 두 개의 둥근 부분까지 만들었다.이번에 덮어쓰는 부분은 매우 간단해서 거의 모든 사람들이 순조롭게 읽을 수 있다.
이번에 제작된 것은 아래 도해의 중간에 있는 두 개의 원, Enties와 Use Cases의 부분이다.원의 안쪽에서 순서대로 이걸 만들어요.

The Clean Architecture by Robert C. Martin (Uncle Bob)

왜 안에서 해요?

내부에서 설치하는 데는 이유가 있다.

1. 손쉬운 설치

원의 안쪽은 의존의 가장 깊은 부분으로 전방에 의존하지 않는다.의존이 없는 부분은 의존 부분을 만드는 Stub입니다. 그 부분이 어떻게 될지 전혀 생각하지 않아도 만들 수 있습니다.

2. 제작물의 본질 파악

원의 안쪽은 본질적으로 표현하고 싶은 추상적이다.UI의 표현에 현혹되지 않고 본질적으로 무엇을 만들고 싶은지 알고 이해를 촉진한다.

3. 실천에 가깝다

실제로 개발된 상황에서 최종적으로 표현된 UI 부분은 종종 끝까지 굳어지지 않는다.그러나 본질적으로 무엇을 표현하는지는 비교 초기에는 큰 변화가 없다.
예를 들어 사용자의 일람을 표시하는 화면을 만들 때 초기에 사용자 실체를 작성하고 이를 API를 통해list로 가져와 목록 모양으로 표시한다.
그러나 실제 UI에서 구체적으로 어떻게 표현되는지는 끝까지 알 수 없으며 중간에 바뀔 가능성이 높다.
예를 들어, 사용자를 목록으로 표시할 경우

TableView

CollectionView

PageView(페이지당 사용자 표시)

이런 여러 가지 설치 방법은 구상할 수 있다.
VC가 사용자를 실제 Cell 등에 직접 전달하여 정보를 표시하도록 설계된 경우 Clean Architecture에서 분할된 모든 구성 요소의 코드가 ViewController를 중심으로 긴밀하게 연결됩니다.UI 변경이 코드에 미치는 영향은 Clean Architecture 디자인에 비해 커질 수 있습니다.

제작 시스템의 개요

사용자 목록을 보기 위한 간단한 시스템을 만듭니다.

프레임 및 폴더 그룹화

VIPER과 Clean Architecture의 혜택을 최대한 누리기 위해서는 각 구성 요소를 프레임으로 분리하는 것이 중요하다.
이것은 의존 관계를 이해하거나 잘못 실시할 위험을 크게 낮추었다.
그리고 한 화면의 개발과 UI 부분, 논리 부분과 다중 분업의 개발도 쉬워졌다.

그룹 구조를 Clean Architecture 원과 일치

Xcode에서 Root 산하의 Group은 모두 Clean Architecture의 원을 나타냅니다.
각 프레임워크와 그 아래의 디렉터리 구조는 기본적으로 Xcode와 일치한다.
그러나 일부 Clean Architecture의 원 구조를 표현하기 위해 Xcode에는 Group이 있지만 실제 폴더를 만들지 않는 부분도 있습니다.
구체적으로 말하면 프레임워크는 모두 루트 바로 아래에 실제 디렉터리를 만듭니다.각 프레임의 디렉토리 구조는 기본적으로 Xcode 그룹과 일치합니다.
그러나 Clean Architecture의 바깥쪽 두 원은 원에 여러 프레임이 있기 때문에 이 부분은 Xcode에 그룹을 만들지만 실제 디렉터리는 만들지 않습니다.그리고 이 부하 그룹은 실제 디렉터리를 가지고 있다.
마지막으로 Clean Architecture 다이어그램의 바깥쪽에 다른 원을 추가합니다.

최종 완성형

이 글은 덮어쓰지 않은 부분을 포함해 모두 완성된 상황에서 이런 구조가 된다.

Outer Circle(without folder)

App Name(framework)

Application(without folder)

Routers

Settings(framework)

View(framework)

Interface Adopter(without folder)

Presenter(framework)

Gateway(framework)

Use Case(framework)

Request Base

Interactors

Entity(framework)

Entities

이번 기사가 만들어진 부분.

사실 이번 보도는 아래 부분만 덮어썼다.

Use Case(framework)

Interactors

Entity(framework)

Entities

구현 준비

가장 내부 실체의 원 부분을 만들기 전에 사전 준비로 Xcode의 구성은 Xcode의 프로젝트를 제작한 후 바로 완성하는 주요 Target의 부분을 가장 원 바깥쪽에서 만드는 또 다른 원의 부분이 된다.
이번에는 UserManager라는 Xcode 프로젝트를 만듭니다.
생성된 후 그룹을 다음 구조로 설정합니다.

Outer Circle(without folder: 신규)

UserManager(처음부터 존재하는 컨텐츠 이동)

응용 프로그램(without folder: AppDelegate 및 Info.plist 등 파일 자동 생성)

첫 번째 원: 솔리드

프레임 및 파일 배치

첫 번째 원의 솔리드 프레임을 만들고 그 아래에 솔리드 디렉터리를 만듭니다.
거기에 사용자가 있습니다.swift 파일을 설정합니다.

Outer Circle(without folder: 신규)

User Manager(기존으로 처음부터 이동)

Entity

Entities

User.swift

User Entity

사용자 엔티티는 다음과 같습니다.
User.swift

public struct User {

    public let id: Int
    public let name: String

    public init(name: String, id: Int) {
        self.id   = id
        self.name = name
    }
}

아무런 변화가 없는 실시이지만 중요한 것은 사용자 실체 자체가 다른 어떤 구조에 의존하지 않는다는 것이다.
실제로 사용자struct는 다른 프레임워크에 접근하지 않고 실체 프레임워크의 목표의 프레임워크와 라이브러리 부분에서 내용을 가져오지 않음으로써 이 점을 보장합니다.

두 번째 원: Cases 사용

프레임 및 파일 배치

UseCase 프레임워크를 추가하고 다음 그림에 따라 제작진 구조를 작성합니다.

Outer Circle(without folder)

UserManager

Application(without folder)

UseCase

Interactors(New!)

UserListInteractor.swift(New!)

Entity

Entities

User.swift

또한 UseCase는 솔리드에 대한 참조가 필요하기 때문에 UseCase의 Target 부분의 Frameworks and Libraries에서 솔리드를 가져옵니다.

Usecase Interactor

여기에 추가된 UserListInteractor는 이번에 이 층에 설치된 Interactor입니다.
UserListInteractor.swift

import Entity

public class UserListInteractor {

    var users: [User] = []
}

이를 통해 알 수 있듯이 사용자 ListInteractor는 실체 단위로 사용자 실체를 직접 참조하고 사용자 ListInteractor는 실체에 의존한다.
그러면 UserListInteractor는 User를 어떻게 나열해야 하나요?게이트웨이가 여기 등장합니다.Gateway에 관해서는 다음 보도에서 처리하겠습니다.

총결산

이번에는 아주 간단한 예지만 실체만 분리돼도 실제로는 큰 이득을 볼 수 있다.작은 항목의 경우 실체만 분리하고 다른 부분은 모두 외측의 원에 넣을 수 있으며 이런 최소한의 프레임 구분도 가능하다.
다음은 드디어 VIPER, Clean Architecture의 중요하고 어려운 부분의 더 바깥쪽 설치로 옮겨집니다.