레이어드 아키텍처
레이어드 아키텍처란?
소프트웨어 시스템을 관심사 별로 여러개의 계층으로 분리한 아키텍처이다.
각각 계층이 서로 독립적으로 구성되어 있어서 한 계층의 변경이 다른 계층에 영향을 주지 않게 설계할 수 있다.
외부의 요구사항이나 세부적인 구현이 변화하더라도, 도메인의 로직을 변경하지 않도록 보호하기 위해서 계층화를 하게 된다.
장점
코드의 재사용성 및 유지보수
각 계층이 관심사별로 분리되어있으므로, 코드의 재사용성과 유지보수성이 향상된다.
변화에 유연하게 대처할 수 있다.
각 계층이 독립적으로 개발, 확장, 변경이 가능하다.
각 계층에서 기능이 확장되거나 변경이 발생했을때 해당 계층의 코드만 변경하면 된다.
테스트 용이성
각 계층을 독립적으로 테스트가 가능하므로, 단위 테스트나 통합 테스트가 편하다.
단점
오버헤드(오버헤드는 특정 기능을 수행하는데 드는 간접적인 시간, 메모리 등 자원)
예를 들어서, 10초 걸리는 기능이 간접적인 원인으로 15초 걸리면 오버헤드는 5초이다.
계층간 통신으로 동작하기 때문에, 데이터 전달 및 변환 과정에서 오버헤드가 발생한다.
계층이 많아 질수록 더 증가한다.
복잡성
계층간 통신을 위해 인터페이스와 로직을 구해야 해서 복잡성이 증가한다.
대규모 프로젝트에서는 계층 간의 관리와 유지보수가 복잡해질 가능성이 크다.
구성
사람마다 구성 요소들이 다른데, 그 이유는 레이어드 아키텍처는 딱 하나로 정의되어 있는게 아니라, 애플리케이션의 크기, 복잡도, 요구사항 등에 따라 달라질 수 있다.
어떤 계층으로 정확히 나눴느냐보다는, 계층을 분리해 각 계층 사이의 의존성을 줄여서 외부 변화로부터 비즈니스 로직의 변화를 막고, 애플리케이션 유지보수와 확장성을 높이려는 목적으로 만들어진 설계의 한 방법일 뿐이다.
다양한 구성이 있는데,
우리는 아마 보통 프레젠테이션 계층, 비즈니스로직 계층, 데이터 저장소 계층으로 구성된 아키텍처를 많이 쓴다.
물론 해당 구성도 다양한 프레임워크와 라이브러리에서 적용이 가능해 일반적으로 많이 쓰인다.
그래서 이번에는 일반적인 레이어드 아키텍처인 4-tier 아키텍처(프레젠테이션, 비즈니스, 영속성, 데이터베이스)를 알아보겠다.
특징
Presentation Layer
사용자 혹은 클라이언트 시스템과 직접적으로 연결되는 부분이다.
이 외에 비즈니스 로직 등은 해당 계층의 관심사가 아니다.
Business Layer
비즈니스 로직을 구현하는 부분이다.
실제로 시스템이 구현해야하는 핵심 로직을 담당한다.
프레젠테이션 레이어로 부터, 요청을 받고 해당 요청을 실질적으로 처리하는 부분이다.
Persistence Layer
데이터의 영구 저장과 관리를 담당하는 부분이다.
웹 애플리케이션의 데이터베이스와의 상호작용을 처리하며, 데이터베이스와의 상호작용을 추상화한다.
Database Layer
실제 데이터베이스이다.
OPEN, CLOSED
CLOSED
레이어드 아키텍처에서 CLOSED는 계층간 요청이 이동할 때 인접한 계층을 통과하는 것이다.
예를 들어서, Presentation Layer → Persistence Layer로 요청이 바로 못가고 Business Layer를 거쳐야하는 것이다.
왜 계층을 뛰어 넘어 바로 접근하는 것이 좋지 않은 방법일까?
이것은 관심사를 분리되지 않은 형태다.
OPEN
그런데 항상 모든 계층이 닫혀 있어야 하는 것은 아니다.
특정 요청은 추가적인 계층이 필요한 경우가 있을 것이다.
예를들면, DB에 이미지를 넣기 전에 합성하는 계층(Services Layer)을 추가하고 싶을때 이 기능은 해당 기능을 사용하는 요청에만 필요하다.
이럴때 해당 기능을 사용하는 요청은 Service Layer를 거치고, 나머지 요청은 우회하도록 한다.
이 같이 특정 계층을 우회하고, 그 아래의 계층으로 이동할 수 있게 하는 것을 개방한다(OPEN)이라고 말한다.
그래서 계층 아키텍처는 계층 구조와 요청 흐름을 문서화하는 것이 아주 중요하다.
어떤 계층이 열려있고, 닫혀 있는지, 그 이유까지 문서화 하거나 적절하게 전달해야 한다.
그렇지 않으면 유지 관리, 테스트, 배포 등에서 많은 어려움을 겪게 된다.
싱크홀 패턴
요청이 하위 레이어를 거치긴하지만, 그 레이어에서 추가적인 작업 없이 전달만하는 경우를 뜻 한다. → 불필요한 오버 헤드
public class UserService {
private final UserRepository userRepository;
/***/
public User find(int userId) {
return userRepository.findById(userId);
}
}이런 경우, 레이어를 개방해서 상위 레이어에서 바로 요청을 하는 방식으로 수정할 수 있다.
그런데 이건 사람마다 다 달라서 적절하게 선택하는데, 블로그에서 일반적으로 80-20 규칙을 따른다고 한다.
요청 20%는 단순 통과 처리하고, 80%는 비즈니스 로직을 수행한다는 규칙이다.
이 비율이 역전되고, 단순 통과 처리되는 요청이 많아지면 해당 레이어를 개방하는걸 고려할 수 있다.
참고 자료
Last updated