레이어드 아키텍처

https://www.oreilly.com/content/software-architecture-patterns/

 

레이어드 아키텍처 (n티어 아키텍처)는 일반적으로 많이 사용되는 아키텍처이다. 더 나은 아키텍처 대안을 찾지 못할 때, 쉽게 선택하는 아키텍처 패턴이다. 

Spring Project에서 각 레이어는 다음과 같은 클래스로 구현된다.

• Presentation Layer : Controller
• Business Layer : Service
• Persistence Layer : Entity
• Database Layer : Repository 

특징

레이어드 아키텍처는 작고 간단한 서비스를 만들 때, 출발점으로 적합한 아키텍처다.

개발자에게 익숙하고, 복잡도도 낮기 때문에 소규모 애플리케이션에 적합하다.

단점

• 계층형 아키텍처는 영속성 계층을 토대로 만들어지기 때문에, 데이터베이스 주도 설계를 유도한다.
  • 계층형 아키텍처에서 ORM 프레임워크를 사용하면, 데이터베이스 중심적인 아키텍처가 되기 쉽다.
  • 영속성 계층에 비즈니스 로직을 추가하고 싶어지기 때문이다. 
  • 혹은 비즈니스 계층에서 영속성 모델을 비즈니스 모델처럼 사용하게 되어, 비즈니스 계층에 영속성 계층에 대한 로직이 추가될 수도 있다. 
• 상위 계층에 있는 컴포넌트가 필요한 경우, 컴포넌트를 아래로 내려서 문제를 해결하는 경우가 있다.
  • 이 경우, 영속성 계층 (최하단)이 비대해질 수 있다.
  • 상위 계층에서 영속성 계층을 계속 참조하면, 하나의 코드 수정 범위가 넓어질 수 있다.
• 상위 레이어에서 하위 레이어에 직접 접근하는 코드가 늘어나, 테스트를 하기 어려워질 수 있다.
  • 예를 들어, 컨트롤러에서 직접 엔티티와 리포지토리를 조회하는 경우가 생길 수도 있다.
• 하나의 서비스를 여러 컨트롤러에서 사용하게 되어, 유스케이스를 유추하기 어렵게 만든다.
• 동시 작업이 어렵다. 

때문에 레이어드 아키텍처는 규모가 커질 수록 유지 보수가 어려워진다.

대규모 애플리케이션에서는 더 모듈화된 아키텍처가 적합하다. 

 

고려사항

레이어드 아키텍처에서는 싱크홀 안티패턴을 조심해야한다. 

요청이 한 레이어에서 다른 레이어로 이동할 때, 각 레이어가 아무 비즈니스 로직도 처리하지 않고 그냥 통과시키는 패턴을 말한다.

 

 

참고

소프트웨어 아키텍처 101

만들면서 배우는 클린 아키텍처