[항해 25일 차] 레이어드 아키텍처_Layered Architecture

코드 아키텍처를 구상할 때는

확장성(extensibility), 재사용성(reusability), 유지 보수 가능성(maintainability), 가동성(readability)

와 같은 요소들을 염두해야 한다.

 

코드의 구조를 구성하고 관리하는 틀로써 만들어진 많은 패턴이 존재한다.

그 중, 백엔드 API 코드에 가장 널리 적용되는 패턴 중 하나인 레이어드 아키텍처 패턴에 대해서 알아보고자 한다.

 

Layered Architecture

Multi-tier 아키텍처 패턴이라고도 불리는 레어이드 아키텍처 코드는

논리적인 부분 혹은 역할에 따라 독립된 모듈로 나누어서 구성하는 패턴이다.

그리고 각 모듈이 서로의 의존도에 따라 층층히 쌓듯이 연결되어 전체의 시스템을 구현하는 구조이다.

 

각 시스템 마다 경우가 다를 수 있으나 일번적으로는 보통 다음과 같은 4개의 표준 레이어가 존재한다.

• Presentation Layer
• Business Layer
• Persistence Layer
• Database Layer

Presentation Layer

해당 시스템을 사용하는 사용자 혹은 클라이언트 시스템과 직접적으로 연결되는 부분이다.

웹 사이트에서는 UI 부분에 해당하고 백엔드 API 에서는 엔드 포인트 부분에 해당한다.

Presentation Layer 에서 API 의 엔드포인트들을 정의하고 전송된 HTTP 요청(request)를 읽어 들이는 로직을 구현한다.

 

다음과 같은 역할을 담당한다.

• End Point
• Authentication
• JSON Translation

 

Business Layer

비즈니스 로직을 구현하는 부분이다.

실제 시스템이 구현해야하는 로직을 해당 레이어에서 구현하게 된다.

백엔드 API 에서는 Presentation Layer 에서 전송된 요청을 읽어들여 요청에 맞게 동작하는 로직을 구현하면 된다.

 

다음과 같은 역할을 담당한다.

• Business Logic
• Validation
• Authorisation

 

Persistence Layer

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

Business Layer 에서 필요한 데이터를 생성, 수정, 읽기 등을 처리하여 실제로 데이터베이스에서

데이터를 저장, 수정, 읽어 들이기를 하는 역할을 한다.

 

다음과 같은 역역할을 담당한다.

• Storage Logic

 

Database Layer

데이터를 보관하는 부분이다.

 

특징

• 레이어드 아키텍처의 핵심 요소는 단방향 의존성이다.
  각각의 레이어는 오직 자기보다 하위에 이는 레이어에만 의존한다.
  
  
• 또다른 핵심 요소는 관심사의 분리이다.(Separation of concerns)
  즉, 각 레이어의 역할이 명확하다라는 의미이다.
  예를 들어 비즈니스 레이어는 데이터를 어떻게 받아야 하는지, 화면에는 어떻게 보여줄건지
  전혀 관여하지 않는다.
  따라서 기술적인 부분에 집중할 수 있지만,(장점)
  변화에 반응하는 능력은 떨어진다.(단점)
  
  
• 도메인 변경의 어려움이 있다.(단점)
  도메인 분할 아키텍처와 반대로 기술의 역할에 따라 묶는데,
  이는 어떤 도메인은 모든 레이어에 분산되게 된다는 것이다.
  예를 들어 '고객' 도메인을 변경하려면 프레젠테이션, 비즈니스, 서비스, 데이터베이스 등을 모두 변경해야한다.
  이러한 이유로 레이어드 아키텍처 패턴은 도메인 주도 설계 방식과 잘 맞지 않는다.
  
  
• 레이어의 격리가 이루어져 있다.
  각 레이어는 폐쇄(closed) 또는 개방(open) 상태이다.
  폐쇄 레이어란 요청이 상위 레이어에서 하위 레이어로 이동하므로 중간에 어떤 레이어도 건너 뛸 수 없다.
  가능한 폐쇄 레이어로 설계하는 것이 유지 보수에 유리하다.(장점)
  (개방 레이어보다 컴포넌트 간의 상호 의존도가 낮음)
• 싱크홀 안티 패턴(Architecture Sinkhole) (주의)
  아키텍처 싱크홀 안티 패턴이란,
  요청이 한 레이어에서 다음 레이어로 이동할 때 각 레이어가 아무 비즈니스 로직도 처리하지 않고
  그냥 통과하는 것을 말한다.
  이런 흐름은 불필요한 객체 초기화 및 처리를 빈번하게 유발하고 쓸데없이 메모리를 소모하며 성능에도 부정적인 영향을 준다.
  (전체 요청의 20%가 싱크홀인 정도면 괜찮은 수준이라고 할 수 있다.)

 

위와 같은 요소들 때문에 레어이드 아키텍처의 각 레이어들은 독립적이고 역할이 분명하므로
코드의 확장성이 높아지고, 코드의 구조를 파악하기 쉬울 뿐 아니라 재사용 가능성도 높아진다.

 

Layered Architecture 패턴을 왜 사용하는가?

• 작고 단순한 앱이나 웹사이트에 알맞는 아키텍처이다.
• 그리 복잡하지 않고 어쩌면 비용도 가장 저렴한 아키텍처 패턴이므로 소규모 애플리케이션을 간편하게 개발할 수 있다.
• 물론 규모가 커질수록 유지 보수, 민첩성, 시험성, 배포성 같은 특성이 점점 나빠진다.

 

<참고>

[Backend] 백엔드 API 패턴 - 레이어드 아키텍처 패턴(layered architecture)

 

소프트웨어 아키텍처 - 레이어드 아키텍처(Layered architecture)