[아키텍처] 클린 아키텍처 (Clean Architecture)

클린 아키텍처의 등장 배경

Hexagonal Architecture, Growing Object Oriented Software, Onion Architecture, Screaming Architecture, DCI, BCE

Robert C.Martin 이 위에 언급한 아키텍처들을 단일 실행 가능한 아이디어(single actionable idea)로 통합하려는 시도이다.

 

따라서 클린 아키텍처는 추상화 개념을 이용하여 관심사를 분리시키고 의존도를 낮추는 것에 목적을 둔 아키텍처라고 볼 수 있다. 이렇게 분리된 관심사는 비즈니스 규칙을 위한 계층과 인터페이스를 위한 계층으로 나뉘어진다.

 

클린 아키텍처의 특징 및 장점

1. 프레임워크에 독립적이다.

    클린 아키텍처에서 애플리케이션은 라이브러리의 존재에 구속되지 않는다.

 

2. 비즈니스 규칙에 대한 독립적 테스트가 가능하다.

    비즈니스 규칙을 ui, 데이터베이스, 웹 서버 등 기타 외부요소 없이 테스트 할 수 있다.

 

3. UI 에 독립적이다.

    예를 들어, 비즈니스 규칙을 변경하지 않고 웹 UI를 콘솔 UI로 대체할 수 있다.

 

4. 데이터베이스에 독립적이다.

    비즈니스 규칙은 DBMS에 구속되지 않으므로 다른 DBMS로 교체 가능하다.

 

5. 외부 기관(external agency)에 독립적이다.

    비즈니스 규칙은 외부 세계에 대해 전혀 알지 못한다.

 

클린 아키텍처 구조

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

 

위와 동일한 원을 파이모양으로 표현한 그림이다. 개인적으로 한눈에 보기 편해서 함께 첨부한다.

 

그림 속 동심원은 소프트웨어의 여러 영역을 나타내며 안으로 들어갈수록 소프트웨어의 수준(level)이 높아진다.

외부 원은 매커니즘(mechanism)이고 내부 원은 정책(policies)이다.

여기서 의미하는 수준(Level)은 입/출력과의 거리를 의미하는 것으로,
고수준 정책은 보통 UI 또는 인터페이스와 거리가 먼 비즈니스 영역 Business Rules, Entities 등을 의미하며,
저수준 정책은 위와 반대로 거리가 가까운 인프라 영역이나 UI 영역 Presentation, Controllers 등을 의미한다.

 

 

계층 설명

Entities (엔티티)

Enterprise 규모의 비즈니스 데이터를 포함하거나 핵심이 되는 비즈니스 규칙을 캡슐화한 것이다.

• 하나 이상의 프로그램 간에 공유될 수 있다는 가정 하에 만들어지므로 수명이 김
     (따라서 재사용성의 가능성이 높다는 것을 인지하고 외부에 의해 변경될 가능성을 낮추어야 함)
• 만일 엔터프라이즈가 없고 단일 애플리케이션만 작성하는 경우, 엔티티는 애플리케이션의 비즈니스 객체

 

Use Cases (유스케이스)

애플리케이션 별 비즈니스 규칙을 포함하며 시스템의 모든 usecase(업무 서비스)캡슐화하고 구현한다.

• 이 계층의 변경사항은 엔티티에 영향을 미쳐서는 안되고, 인프라 단의 DB 나, UI, 라이브러리와 같은 외부요소에 의해 영향을 받지 않는다는 것을 원칙으로 함
  (즉, 고수준 정책이 저수준 정책의 변경에 영향을 받지 않는다는 말)

 

Interface Adapters (인터페이스 어댑터)

어댑터 계층은 DB나 Web, UI 와 같은 바깥 계층에서 사용하기 편리하도록 유스케이스 또는 엔티티 계층에서 데이터를 변환하는 어댑터의 집합이다.

• Controller
  • 클라이언트의 요청을 받아서 UseCase 나 서비스 계층으로 전달
  • 비즈니스 로직을 직접 처리하지 않고 요청을 어댑터로 전달하여 시스템을 분리
• Presenter
  • UI 와 UseCase 계층 사이를 연결하는 역할
  • UseCase 와 View 사이에서 데이터를 변환하는 역할
• Gateway
  • 외부 시스템과의 통신을 처리하는 어댑터 역할
  • ex) DB나 외부 API와의 연결을 처리할 때 Gateway를 사용
  • 비즈니스로직(UseCase)는 Gateway 에 의존하지 않고 Port 를 통해 의존성을 역전시켜 외부시스템과 연결

 

Frameworks & Drivers (프레임워크와 드라이버)

Devices, DB, External Interface, UI, Web 으로 구성된다.

 

✨ 종속성 규칙

클린 아키텍처를 관통하는 가장 중요한 규칙이자 원리는 종속성 규칙이며, 이는 매우 직관적이다.

각 코드의 종속성은 반드시 외부에서 내부로 향해야 한다.

 

위의 원리를 지키기 위해 소스코드의 종속성은 반드시 내부를 가리키는 방향으로 코드를 작성해야 한다.
또한 내부 원은 외부 원에 대해 어떠한 것도 알 수 없으므로 외부 원에 존재하는 모든 것은 내부 원에서 언급조차 되지 않는다. (ex: 함수, 클래스, 변수, 명명된 소프트 엔티티)

 

경계 넘기 (Crossing boundaries)

그림 우측 아래에 계층 간 경계를 넘는 방법에 대한 예시가 표현되어 있다.

Flow of control을 보면 Controller -> UseCase -> Presenter 로 플로우가 흐르고 있다.

 

종속성 규칙에 따라 UseCase(내부) 는 Presenter(외부) 를 직접 호출할 수 없다.

따라서 DIP(의존 관계 역전 법칙) 를 활용하여 내부에 인터페이스를 선언하고 외부에서 해당 인터페이스를 구현시키는 방식으로 내부는 외부에 접근할 수 있다.

 

 

같이 읽으면 재미있을 것 같은 포스팅

클린아키텍처 썼는데 왜 프로젝트가 더 더러워지지

 

 

참고

https://daryeou.tistory.com/280#google_vignette

 

https://sunny-maneg.tistory.com/entry/%ED%81%B4%EB%A6%B0%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90Clean-Architecture

 

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html