노트필기) FastAPI로 배우는 백엔드 프로그래밍 with 클린 아키텍처 (챕터 2)
챕터2. 클린 아키텍처
2.3 클린 아키텍처의 주요 4계층
안쪽 원에 존재하는 구성 요소는 바깥쪽에 독립적이다.
클린 아키텍처의 개념을 정립한 로버트 C. 마틴은 원문에서 각 계틍의 이름을 안쪽의 계층부터 각각 '엔티티', '유스 케이스', 인터페이스 어댑터', '프레임워크 및 드라이버'라고 했다.
이 책에서는 이름을 변경해서 부른다
- 엔티티 -> 도메인
- 유스 케이스 -> 애플리케이션
- 인터페이스 어댑터 -> 인터페이스
- 프레임워크 및 드라이버 -> 인프라스트럭처(인프라)
2.3.1 도메인(엔티티) 계층
도메인 계층은 소프트웨어 시스템 내에서 핵심 비즈니스 로직과 엔터프라이즈의 핵심 도메인 관련 기능을 관리하고 구현하는 부분이다. 도메인이 가지는 비즈니스 로직(도메인 규칙)은 시스템의 핵심 목적을 달성하기 위한 연산, 규칙, 데이터 처리 및 동작을 정의한다.
도메인 계층은 데이터베이스 스키마, 사용자 인터페이스 또는 외부 시스템에 대한 의존성을 갖지 않아야 한다
2.3.2 애플리케이션(유스 케이스) 계층
특정 기능과 유스 케이스를 정의하고 구현. 애플리케이션 계층의 모듈은 도메인 계층에 대한 접근 권한이 있다.
2.3.3. 인터페이스 (인터페이스 어댑터) 계층
시스템의 외부와 내부 간의 인터페이스 역할
- 외부와 내부 사이의 데이터 변환
- 인터페이스 구현
- 외부 종속성의 분리
클린 아키텍처에서는 의존성 역전을 주요하게 다룸. 안쪽 계층의 구성 요소가 바깥쪽 계층의 구성 요소를 사용하고자 한다면 인터페이스를 이용하고, 그 인터페이스의 구현체를 외부의 계층에 둘 것.
-> 데이터베이스와의 인터페이스 상황에 따라 인터페이스 계층이나 애플리케이션 계층 모두에서 사용 가능
- 컨트롤러 : UI를 통해 전달된 사용자의 입력과 요청을 내부로 전달. 웹앱에서는 HTTP 리퀘스트 처리
- 게이트웨이 : 외부 데이터 소스와의 통신 담당. 외부 데이터를 내부 시스템에서 사용할 수 있는 형식으로 변환
- 프레젠터 : 내부 유스케이스가 처리한 데이터를 사용자가 볼 수 있는 형태로 가공. 템플릿 구성, JSON, HTML 등 데이터 구성
2.3.4 인프라스트럭처 (프레임워크 및 드라이버) 계층
내부 시스템이 사용하고자 하는 외부 시스템을 다룬다. 예시) 데이터베이스 조회 SQL 쿼리 -> '조회'인터페이스 구현
인프라 계층은 내부에서 제공하는 인터페이스를 구현하는 구현체들로 이루어 짐
2.4 의존관계 역전 원칙
클린 아키텍처의 의존성 규칙은 의존성의 방향이 안으로 향하는 데 있다.(그림 2-1의 화살표)
고수준의 구성 요소가 저수준의 데이터 형식에 의존하면 안 된다. 외부 변경으로 부터 내부 요소를 격리 보호하기 위함.
고수준의 구성 요소는 같은 계층에 있는 인터페이스를 이용해 바깥 계층의 요소를 다루어야 한다! -> 의존성 역전
기타 SOLID로 널리 알려진 객체지향 설계 원칙
- 단일 책임 원칙 : 한 클래스는 하나의 책임만 가져야 한다
- 개방 폐쇄 원칙 : 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다
- 리스코프 치환 원칙 : 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다
- 인터페이스 분리 원칙 : 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
2.5 마무리
클린 아키텍처의 목표는 소프트웨어의 유연성을 향상하고 유지보수성을 증가시키는 것.
도메인 계층 - 시스템의 핵심 로직
애플리케이션 - 유스케이스 구현에 필요한 비즈니스 로직
인터페이스 계층 - 시스템이 외부 세상과 소통
인프라 계층 - 외부 시스템을 다루는 구현체
가장 중요한 것은 의존성 규칙. 고수준(안쪽 계층)의 구성 요소는 저수준(바깥쪽 계층)의 구성 요소에 직접 의존하면 안 된다. 이럴 경우 인터페이스를 정의해 사용해야 한다.