FastAPI로 배우는 백엔드 프로그래밍 - 클린 아키텍처

이 글은 'FastAPI로 배우는 백엔드 프로그래밍 with 클린 아키텍처' 책을 읽고 공부하며 작성한 글입니다.
책 정보: https://product.kyobobook.co.kr/detail/S000214428277

 

이전글

FastAPI로 배우는 백엔드 프로그래밍- FastAPI 소개 (https://joykim-dev.tistory.com/31)

FastAPI로 배우는 백엔드 프로그래밍 - FastAPI 소개

---

아키텍처

아키텍처(architecture): 시스템의 전체적인 구조 및 구성을 의미한다.
클린 아키텍처(clean architecture): 클린코드의 저자 로버트 C. 마틴이 제안한 아키텍처

소프트웨어에서 아키텍처는 신중하게 검토해서 적용해야 한다.

아키텍처의 역할

• 확장성(scalability): 요구사항 추가 시 새로운 기능 추가가 쉬움
• 유지보수성(maintainability): 모듈화, 명확한 구조로 인해 유지보수 및 개선이 쉬움
• 재사용성(reusability): 모듈화, 추상화를 통한 코드 재사용
• 보안(security)
• 성능(performance): 데이터 흐름 및 리소스 사용을 효과적으로 관리
• 의사소통(communication): 명확한 구조로 이해 관계자 간의 의사소통을 간소화함
• 비용 효율성(cost-effectiveness): 프로젝트 비용 최적화
• 기업 목표 달성(business goal)
• 품질 보증(quality assurance)
• 복잡성 관리(complexity management): 모듈화, 추상화를 통한 복잡성 관리 및 감소

 

클린 아키텍처의 특징

• 관심사 분리와 계층형 아키텍처: 관심사에 따라 요소들을 분리
• 인터페이스 우선: 구성 요소들의 인터페이스를 먼저 정의해 사용
• 의존성 규칙
  • 핵심 원칙
  • 소스 코드 의존성은 언제나 외부에서 내부로 향해야 한다.
  • 가장 중요한 코드는 시스템의 중심에 있어야 한다.

---

분할 정복

분할 정복(divide and conquer): 큰 문제를 해결할 수 있는 작은 하위 문제로 나눠 해결하고, 마지막에 해결책들을 통합해 큰 문제를 해결하는 방법

1. 큰 문제를 더 작은 하위 문제로 분할
2. 하위 문제를 독립적으로 해결
3. 각 하위 문제의 해결책을 통합해 본 문제의 해결책 모색

분할 정복 기법을 이용하면 작업 복잡도가 낮아지고, 이해가 쉬워져 난이도를 낮출 수 있다.
아키텍처의 관점에서 이는 모듈을 구조화하는 것으로 볼 수 있다.
나누어진 계층의 일을 처리할 때는 다른 계층에서 맡은 일은 고려하지 않고 현재 계층이 담당하는 구현에 집중한다. 

역할이 나누어져 있으므로 작성해야 하는 전체 코드의 양은 많아질 수 있으나, 한 계층 내의 코드의 양은 줄어든다.

---

클린 아키텍처의 주요 4 계층

클린 아키텍처는 육각형 아키텍처(hexagonal architecture), 양파 아키텍처(onion architecture)라고 불리던 아키텍처에 발전했다.

가장 바깥쪽 가장 안쪽	*프레임워크 및 드라이버(인프라)
	*인터페이스 어댑터(인터페이스)
	*유스 케이스(애플리케이션)
	*엔티티(도메인)

*클린 아키텍처 원문 계층: 프레임워크 및 드라이버 - 인터페이스 어댑터 - 유스 케이스 - 엔티티
*책에서 제안한 계층: 인프라 - 인터페이스 - 애플리케이션 - 도메인

안쪽으로 갈수록 고수준 구성 요소가 된다.
고수준 코드나 개념은 더 큰 개념이나 추상화된 표현을 사용하고 세부 사항은 명시하지 않는다.

도메인(엔티티) 계층

도메인(domain): 애플리케이션이 해결하고자 하는 특정한 주제나 분야
도메인 모델(domain model): 비즈니스 영역에서의 도메인의 핵심 개념, 엔티티, 관계, 규칙 및 상태

참고로 장고에의 도메인 모델은 테이블 스키마를 기술하는 것을 말한다.

도메인 계층(domain layer)은 비즈니스 도메인에서의 실제 개념이나 객체를 표현한다.
도메인 계층은 독립적으로 존재한다.
데이터베이스 스키마(database schema), 사용자 인터페이스(UI) 또는 외부 시스템에 대한 의존성을 갖지 않아야 한다.
그렇기 때문에 테스트가 상대적으로 간단하다.

도메인은 애플리케이션이 가져야 하는 핵심 요소만 가진다.
도메인 계층 요소가 변경되면 다른 모든 계층을 수정해야 하니 주의해야 한다.

 

애플리케이션(유스 케이스) 계층

애플리케이션이 해결하고자 하는 문제와 해결 방법이 있고, 이에 대한 기능과 유스케이스를 정의하고 구현하는 계층이다.

주로 비즈니스 로직을 수행하는 모듈인 서비스로 이루어진다.
작업을 별도의 작은 유스 케이스와 서비스로 분리하면 전체 시스템을 테스트하고, 관리하기에 더 쉽다.

애플리케이션 계층의 모듈은 도메인 계층에 대한 접근 권한이 있다. → 도메인 인스턴스 생성 가능
서비스는 서로를 호출할 수 있다. → 간단한 유스 케이스로 구성된 복잡한 유스 케이스를 만드는 것이 일반적

 

인터페이스(인터페이스 어댑터) 계층

인프라 계층의 시스템과 애플리케이션 및 도메인 계층을 연결하는 역할을 한다.

• 외부와 내부 사이의 데이터 변환
• 인터페이스 구현: 외부 시스템과의 통신을 담당.
• 외부 종속성 분리

 

기존 계층형 아키텍처에서는 계층 간의 역할을 엄격히 지키도록 했음 → 유연성이 떨어질 수 있음
클린 아키텍처는 의존성 역전을 중요시함 → 안쪽 계층의 구성 요소가 바깥쪽 계층의 구성 요소를 사용하려면 인터페이스를 이용하고, 그 구현체는 외부 계층에 둔다.

인터페이스 계층은 애플리케이션 계층과 도메인 계층에 직접 의존성을 가져도 된다.
인터페이스 계층에는 컨트롤러(controller), 게이트웨이(gateway), 프레젠터(presenter)가 사용된다.

 

인프라스트럭처(프레임워크 및 드라이버) 계층

내부 시스템이 사용하고자 하는 외부 시스템을 다룬다.

인프라 계층은 사용자 인터페이스, 디바이스, 웹 프레임워크, 데이터베이스 등과 같은 외부 환경과의 상호작용을 담당한다.
인프라 계층은 내부에서 제공하는 인터페이스를 구현하는 구현체들로 이루어진다.

---

의존관계 역전 원칙

계층을 나누다 보면 각 계층의 구성 요소는 다른 계층의 구성 요소를 가져다 쓰게 된다. → 의존성 발생

클린 아키텍처의 의존성 규칙은 의존성의 방향이 안으로 향하는 데 있다.
고수준 데이터 형식은 저수준에서 자유롭게 사용 가능하지만, 그 반대로 저수준의 데이터 형식에 의존하면 안 된다.
이는 외부 변경으로부터 내부 요소를 보호하기 위함이다.