Clean Architecture

간단 요약한 클린 아키텍처

!! 소프트웨어를 계층으로 나누어 관심사를 분리하자.

대출하기 앱을 만든다고 가정할 때, 아래와 같은 기능이 존재한다.

1. 대출하기 버튼

2. 버튼을 누르면 대출하기를 실행

3. 대출 정보를 저장할 공간

3가지를 계층 구조로 분리시켜 보자.

1. Presentation

• UI (버튼) : 버튼을 클릭하면 Controller로 전달

• Controller : 버튼의 액션을 받고 도메인과의 번역을 담당. 여기서 Usecase를 실행한다.

2. Domain

• Usecae (대출하는 비즈니스 룰을 담은 Usecase이다.)

  • 대출에 필요한 Entity들을 통해 최종 결정한다.

  • 대출이 실행되면 이를 Repository에 반영한다.

  • 필요에 따라서 Usecae에서 변화된 값을 다시 Controller로 전달

• Entity (핵심 기능을 가진 엔터프라이즈 비즈니스 룰을 담은 Entity)

3. Data

• Repository : 서버가 될 수도 있고 로컬 DB가 될 수도 있다.

Layer

Presentation Layer와 Data Lyaer는 쉽게 변할 수 있는 영역이다. Domain Layer는 쉽게 변하지 않는 비즈니스 Rule이 담긴 공간이다. 따라서 서버에 저장하거나 로컬에 저장하거나 도메인을 알 필요가 없다. 또한 UI의 버튼 모양이 네모이던 세모이던 도메인은 전혀 알 필요가 없다.

각 레이어와 의존성을 표현해보자.

가장 밖에 존재하는 Infrastructure(Presentation / Data)들은 쉽게 변경이 가능한 영역이고, 내부 Domain은 쉽게 변하지 않는 영역이다. 의존성은 밖 --> 안으로 흐른다. 때문에 도메인은 외부 영향을 받지 않고, 알 이유도 없다.

S/W를 계층으로 나누어 관심사를 분리하자.

계층 나누기와 관심사 분리를 통해 다음과 같은 이득을 취할 수 있다.

1. 명확한 책임과 계층으로 인해 소스코드 전반을 쉽게 파악이 가능해진다.

2. 수정 사항에 대한 대응이 쉬워진다.

3. 수정이 다른 계층에 영향을 주지 않는다.

4. 따라서 테스트 또한 쉬워진다.

계층으로 나누어 관심사를 분리한 결과 "높은 응집도"와 "낮은 결합도"를 얻었다. 이는 즉, "높은 생산성"을 얻은것이다.

초기 구축 비용은 더 들겠지만 이후에 변화에 유연하게 대응할 수 있고 높은 생산성으로 보답해 줄 것이다.

Summary

Q : 왜 클린 아키텍처를 사용하는가?

A : 높은 생산성을 바탕으로 사용자에게 빠르고 안전하게 서비스를 제공하기 위함이다.