Layered Architecture

코드를 구상할 때 고려해야 할 점은 여러 가지가 있다. 그리고 하나의 요소가 어려울 수 있는 요소이기 때문에 좋은 코드의 구조를 생각해 내는 것은 쉽지 않다. 다행히 코드의 구조를 어떻게 구성하고 관리해야 하는 문제는 이미 많이 다루어진 문제이고, 그에 관한 정석이나 패턴은 굉장히 많이 나와 있다.

Back_end API 코드에 가장 널리 적용되는 패턴 중 하나는 레이어드 아키텍처 패턴이다.

Multi-tier 아키텍처 패턴이라고도 하는 레이어드 아키텍처는 코드를 논리적인 부분 혹은 역할에 따라 독립 된 모듈로 나누어서 구성하는 패턴이다. 그리고 각 모듈이 서로의 의존도에 따라 층층히 쌓듯이 연결되어서 전체의 시스템을 구현하는 구조다.

일반적으로 보통 다음과 같은 3개의 레이어가 존재한다.

• Presentation Layer
• Business Layer
• Persistence Layer

Presentation Layer

presentation layer는 시스템을 사용하는 사용자 혹은 클라이언트 시스템과 직접적으로 연결되는 부분이다. 웹사이트에서는 UI, 백엔드 API에서는 엔드포인트 부분에 해당한다. 그러므로 presentation layer에서 API의 엔드포인트들을 정의하고, 전송 된 HTTP request들을 읽어 들이는 로직을 구현한다.

실제 시스템이 구현하는 비즈니스 로직은 다음 layer로 넘기게 된다.

Business Layer

이름 그대로 비즈니스 로직을 구현하는 부분이다. 실제 시스템이 구현해야 하는 로직들을 이 레이어에서 구현하게 된다. 예를 들어, tweet이 300자가 넘는지 확인하여 300자가 넘으면 해당 tweet을 거부해야 하는 로직 등이 비즈니스 로직이며, 바로 business layer에서 구현하게 된다.

Persistence Layer

데이터베이스와 관련 된 로직을 구현하는 부분이다. Business Layer에서 필요한 데이터 생성, 수정, 읽기 등을 처리하여 실제로 데이터베이스에서 데이터를 저장, 수정, 읽기를 하는 역할을 한다.

핵심 요소

의존성

레이어드 아키텍처의 핵심 요소는 바로 단방향 의존성이다. 각각의 레이어는 오직 자기보다 하위에 있는 레이어에만 의존한다.

따라서, Presentation layer → Business Layer → Persistence Layer 의 방향으로 의존한다.
이 말은 반대의 경우에 대해서는 완전히 독립한다는 뜻이다.

separation of concerns

각 레이어의 역할이 명확하다는 뜻이다. Presentation layer에는 Business 로직이 전혀 구현되어 있지 않다. 비즈니스 로직을 처리하기 위해서 presentation은 business layer의 코드를 호출해서 사용해야 한다.