코드 아키텍처를 구상할 떄는 확장성, 재사용성, 유지 보수 가능성, 가독성과 같은 요소들을 염두해야한다. 그 중에서 백엔드 API 코드에 가장 널리 적용되는 패턴 중하나가 레이어드 아키텍처 패틴이다.
레이어드 아키텍처 패턴
스프링 프로젝트 내부에서 어떻게 코드를 적절히 분리하고 관리할 것이냐에 대한 이야기
레이어드 아키텍처는 코드를 논리적인 부분 혹은 역할에 따라 독립된 모듈로 나누어서 구성하는 패턴이다. 각 모듈이 서로의 의존도에 따라 층층이 쌓듯이 연결되어서 전체의 시스템을 구현하는 구조이다. 마치 레이어(layer)를 쌓아 놓은 것 같은 형태의 구조!
레이어드 아키텍쳐 패턴은 프로젝트 내부에서 어떻게 코드를 관리할 것인가에 대한 내용이라면, REST 아키텍처는 클라이언트(브라우저)가 우리 서비스를 이용하려면 어떤 형식으로 요청을 보내고 응답을 받는지에 대한 이야기이다.
Presentation layser(User interface)
해당 시스템을 사용하는 사용자 혹은 클라이언트 시스템과 집적적으로 연결되는 부분입니다. 웹 사이트에서는 UI 부분에 해당, 백엔드 API에서는 엔ㄷ포인터 부분에 해당한다. 따라서 API의 엔드포인터들을 정의하고 전송된 HTTP요청을 읽어 들이는 로직을 구현한다.
- EndPoint
- Authentication
- JSON Translation
Business layer(Business Logic)
실제 시스템이 구현해야하는 로직을 이 레이어에서 구현. 요청에 맞게 동작하는 로직을 구현하면 된다. 예를 들어 회원가입 요청 시 필수적인 요소들이 다 포함되어 있지 않으면 거부한다던가....
- Business Logic
- Validation
- Authorisation
Persistence Layer(Data Access)
Business layer에서 필요한 데이터를 생성, 수정, 읽기 등을 처리하여 실제로 데이터베이스에서 데이터를 저장, 수정, 읽어 들이기를 하는 역할을 한다.
- Storage Logic
특징
-
레이어드 아키텍처 패턴은 애플리케이션을 구성하는 요소들을 수평으로 나눠 관리하는 것이다.
-
레이어를 나눈다는 것은 메서드를 클래스 또는 인터페이스로 쪼개는 것이다.
-
단방향 의존성 : 레이어 사이에는 계층이 있다. 그래서 레이어는 자기보다 한 단계 하위의 레이어만 사용한다.
- 요청 -> 컨트롤러 -> 서비스 -> 퍼시스턴스
- 응답 <- 컨트롤러 <- 서비스 <- 퍼시스턴스
- preentation layer은 business layer에게만 의존하고, business layer는 persistence layer에게만 의존하게 된다!
-
Sepration of Concerns : 레이어의 역할이 명확하다!
- 각 레이어가 독립적이고 역할이 분명하므로 코드의 확장성이 높아진다. 코드의 구조를 파악하기 쉬울 뿐만 아니라 재사용 가능성도 높아진다. 각 레이어를 테스트하는 테스트 코드의 작성도 훨씬 수월!
물론 반드시 정해진대로 하위 레이어만 사용해야하는 것은 아니다. 필요에 따라 서비스가 서비를 사용하기도하고, 레이어가 많은 경우 중간 레이어를 섞어 사용하는 경우도 있다. 하지만 기본적인 레이어드 아키텍처에서는 상위 레이어가 자신의 바로 하위 레이어를 사용한다.
- 그냥 단순한 코드 나열 → 기능들을 메소드로 구분 → 똑같은 기능을 구현할 때마다 복붙하기 귀찮으니 메소드를 클래스로 따로 빼서 만들기
- 메소드를 클래스로 따로 빼서 만들기 → 이것이 레이어로 나누는 것과 동일하다.
참고 : 레이어드 아키텍처
