Clean Architecture

Clean Architecture

소프트웨어 시스템을 특정 목적과 책임을 가진 계층으로 분리하는 디자인 접근방식

클린 아키텍처의 주요 목표는 각 계층을 독립적으로 개발, 테스트 및 배포할 수 있도록하여 유연하고 유지 보수가 용이한 시스템을 만드는 것이다.

왼쪽의 그래프를 보면 여러개의 레이어들이 존재하는 것을 볼 수 있다.

 

이 그래프에서 핵심은 안쪽 레이어들은 바깥 레이어에 있는 것들을 몰라야 한다. 즉 안쪽 레이어에서 바깥 쪽에 의존하지 말아야한다.는 것이다.

 

다시말하면, 바깥쪽 레이어의 객체를 내부에서 생성하면 안된다는 말이다.

그래서 Dependency Rule 화살표가 안쪽을 향하고 있다.

안쪽 레이어에 의존해야 한다는 의미다.

 

Layers

이렇게 레이어를 나눴는데, 여기서 그룹을 지을 수 있다.

Domain 레이어, Presentation 레이어, 그리고 Data 레이어가 있다.

 

Domain Layer(Business Logic)

그래프의 가장 안쪽에 위치한 부분이다.

가장 안쪽에 있으므로 완전히 고립되어 있으며, 바깥의 정보들을 아무 것도 알 수 없다.

 

Entity(Business Model), Use Case, Repository Interface를 포함한다.

이 레이어는 다른 프로젝트에서도 재사용 될 수 있다.

이렇게 레이어가 분리되면 다른 의존성이나 서드파티가 필요하지 않기 때문에 테스트를 쉽게 할 수 있다.

 

Domain Layer의 핵심은 다른 레이어(Presentation의 UI나 Data의 Mapping Codable)의 어떤 것도 포함시키면 안된다.

 

Presentation Layer

UI(UIViewController / SwiftUI View)를 포함한다.

각 View는 하나 이상의 UseCase를 실행시키는 ViewModel(Presenters)와 대응된다.

즉 한 view에 대응되는 하나의 viewModel이 있다.

 

위의 과녁모양 그래프에서도 봤듯이, 도메인 레이어에만 의존하고 있다.

 

Data Layer

Repository Implementation, 그리고 하나 이상의 Data Source를 포함한다.

 

Data Source는 원격이거나 로컬일 수 있다.

원격일 경우 API 호출을 통해 JSON 데이터를 내려받는 경우이고, 로컬일 경우 데이터베이스일 것이다.

Data Layer는 오로지 Domain Layer에만 의존하고 있다.

과녁모양의 그래프에서는 안쪽의 Presenters, 바깥의 DB, API, UI 등이 있었는데 Presenters는 Presentation Layer에 대응되고 Data Layer에 대응되는 것은 아니다.

 

Data Layer에는 네트워크로 받은 JSON 데이터를 Domain Model로 매핑하는 것을 포함시킬 수 있다.

 

Data Flow

위 그림에서는 의존성 방향이 Domain Layer로 향하고 있다.

특히 Repository Interface(protocol)에서 의존성 역전이 일어나는 것을 확인할 수 있다.

근데 의존성 역전이 뭐지?

의존성 역전 원칙

상위 모듈이 하위 모듈에 의존하는 것이 아니라, 둘 모두가 추상화에 의존해야 한다는 소프트웨어 디자인 원칙

의존성 역전 원칙에서는 하위 모듈이 상위모듈에 의존하도록 설계한다.

그래서 인터페이스(Swift에서는 프로토콜)을 통해 접근한다.

상위 모듈과 하위 모듈의 결합도를 낮추고, 모듈 간 의존성을 제어하여 소프트웨어 시스템을 유연하고 확장 가능하게 만든다.

아래의 예시를 보자.

protocol Printer {
    func printMessage(message: String)
}

class ConsolePrinter: Printer {
    func printMessage(message: String) {
        print(message)
    }
}

class Message {
    let printer: Printer
    
    init(printer: Printer) {
        self.printer = printer
    }
    
    func printMessage(message: String) {
        printer.printMessage(message: message)
    }
}

let printer = ConsolePrinter()
let message = Message(printer: printer)
message.printMessage(message: "Hello, World!")

Message클래스(상위모듈)는 ConsolePrinter클래스(하위모듈)에 직접적으로 의존하지 않고,

Printer프로토콜에 의존하게 되어 의존성 역전원칙이 적용된다.

이렇게 인터페이스를 사용해서 모듈 간의 결합도를 낮추고 의존성을 제어한다.

 

 

다시 본론으로 돌아와서,

클린아키텍처에서는  Domain UseCase에서 Data Repository에 의존하고 있으면 안된다.

왜 의존하면 안되는 지 궁금해서 ChatGPT에 물어봤다.

DIP는 의존성 역전 원칙이다.

테스트가 어려워지고 Data Repository의 변경이 UseCase에 영향을 미쳐서 그렇다고 한다.

아.. 그러면 UseCase가 영향을 받게되니까 의존하면 안된다는 것을 알았다.

 

그렇지만 Data Repository(상위모듈)에서는 request와 response를 받아와야한다.

 

이런 상황에서 Data Repository를 사용하기 위해 의존성 역전 원칙을 통해 의존성을 없애면서(위의 예제에서 프로토콜 쓴 것처럼) Domain에서 Data Repository를 사용할 수 있게 한 것이다.

 

그래서 데이터가 오고 가는 흐름은 아래와 같다.

1. 사용자가 버튼을 눌러 View(UI)가 ViewModel(Presenter)의 메서드를 호출한다.
2. ViewModel이 UseCase를 실행시킨다.
3. UseCase가 User와 Repository에서 데이터를 취합한다.
4. 각 Repository는 Remote Data(NW), Persistent DB저장소나 메모리 데이터를 반환한다.
5. 반환된 데이터가 우리가 아이템들을 화면에 출력할 View에 전달된다.

 

의존성 방향

Presentation Layer ➡️ Domain Layer ⬅️ Data Layer

• Presentation Layer(MVVM) = ViewModel(Presenters) + Views(UI)
• Domain Layer = Entities + UseCases + Repositories Interfaces(의존성 역전 원칙을 위한 Protocol)
• Data Layer = Repositories Implementations + API(NW) + Persistence DB

다음 포스팅에서 예제 프로젝트를 다뤄보겠습니다.

---

Ref

https://yoojin99.github.io/app/%ED%81%B4%EB%A6%B0-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98/