[TIL] API Architecture & Layered Pattern

API Architecture란?

코드의 확장성, 재사용성, 유지보수 가능성, 가독성, 테스트 가능성을 위해 코드를 논리적/기능적으로 영역을 구분하여 체계적/효율적으로 구현해 놓은 것을 말한다.

Layered Pattern이란?

백엔드 API 코드에 가장 널리 적용되는 패턴 중 하나로, Multi-tier아키텍처 패턴이라고도 한다. 이 아키텍처는 논리적인 부분/역할에 따라 독립된 모듈로 나누어서 코드를 구성한다.
일반적으로 다음과 같은 3개의 레이어가 존재하며, 각각의 역할에 따라 분리한다.

1) Presentation Layer

• 사용자 혹은 클라이언트 시스템과 직접적으로 연결되는 부분
• API의 엔드포인트들을 정의하고 전송된 HTTP 요청(request)들을 읽어 들이는 로직을 구현

2) Business Layer

• 비즈니스 로직을 구현하는 부분.
• 실제로 검증 등의 작업이 해당 레이어에서 이루어진다.

3) Persistence Layer

• 데이터베이스와 관련된 로직을 구현하는 부분

Layered 아키텍처의 핵심요소

1. 단방향 의존성

각각의 레이어는 오직 자기보다 하위에 있는 레이어에만 의존하고 있음
(routes) -> (가장 상위) controller -> Service -> Model (가장 하위) 순이다.

2. 관심사 분리 (Seperation Of Concern)

각 레이어별 역할이 구분되어 명확하다는 의미이다. 즉, 각 레이어들은 역할이 중첩되지 않는다.

• routes: 라우팅(엔드 포인트 나누기) 로직을 담당한다.
• controllers: 엔드포인트에 해당하는 함수 로직 - http 요청에 따른 에러 핸들링, service 로직에서 데이터를 받아와서 응답으로 내보내는 로직이다.
• services: controller 에서 넘겨받은 인자로 다양한 알고리즘(필터, 정렬 등..)을 처리해서 데이터에 접근하는 로직이다.
• models: 데이터베이스에 접근하기 위한 모델(DAO)이 정의되어 있는 폴더이다.

아래 모듈은 의존성 없이 다양한 레이어에서 사용될 수 있지만,
반복되는 로직이기에 (재사용성을 위해) 분리해놓은 폴더이다.

• middlewares: 컨트롤러에 닿기 전에 반복되는 로직을 모듈화 해 놓는 폴더이다. (ex. validateToken - 인증 / 인가)
• utils: 의존성 없이 모든 레이어에서 공통적으로 자주 사용되는 로직을 모듈화 해 놓는 폴더이다. (ex. errorGenerator)
• .env: 프로젝트 내에서 사용할 환경 변수를 선언해 놓는 곳이며 샘플 양식은 .env.sample에 따로 기입하여 공유이다.
• node_modules: 노드 패키지 모듈이다.
• .gitignore: 해당 모듈을 깃이 관리하지 않도록 한다.
• package.json: 노드 모듈을 관리하는 파일이다.