레이어드 아키텍처(layered architecture, n티어(n-tiered) 아키텍처)는 가장 흔한 아키텍처 스타일 중 하나이다. 단순하고 대중적이면서 비용도 적게 들어 모든 애플리케이션의 사실상 표준 아키텍처이다. 시스템을 설계하는 조직은 그 조직의 소통 구조를 그대로 복제한 듯 설계할 수밖에 없다는 콘웨이의 법칙을 떠올려보면, 레이어드 아키텍처는 애플리케이션을 개발하는 아주 자연스러운 방법이다.

그러나 레이어드 아키텍처 스타일은 묵시적 아키텍처 안티패턴, 우발적 아키텍처 안티패턴 등의 몇몇 아키텍처 안티패턴의 범주에 속한다.

10.1 토폴로지

레이어드 아키텍처에서 내부 컴포넌트는 논리적으로 수평한 레이어들로 구성되며, 각 레이어는 애플리케이션에서 주어진 역할을 수행한다. 레이어의 개수와 유형은 특별한 제한이 없지만, 일반적으로 프레젠테이션, 비지니스, 퍼시스턴스, 데이터베이스의 4개 표준 레이어로 구성한다. 퍼시스턴스 로직이 비지니스 레이어 컴포넌트에 내장된 경우에는 퍼시스턴스 레이어를 비지니스 레이어에 병합시킨다. 따라서 보통 규모가 작은 애플리케이션은 3개, 덩치가 크고 복잡한 비지니스 애플리케이션은 5개 또는 그 이상의 레이어로 구성된다.

위의 그림은 물리적 계층화 관점에서의 다양한 토폴로지 변형이다.

• 왼쪽 : 프레젠테이션, 비지니스, 퍼시스턴스 레이어를 단일 배포 단위로 합한 것으로, 데이터베이스 레이어는 외부에 별도로 분리된 물리적인 데이터베이스로 나타낸다.
• 가운데 : 프레젠테이션 레이어를 자체 배포 단위로 떼어내고 비지니스 레이어와 퍼시스턴스 레이어를 두 번째 배포 단위로 합한 것.
• 오른쪽 : 데이터베이스 레이어를 포함한 4개 표준 레이어를 모두 단일 배포 단위로 뭉뚱그린 것.

레이어드 아키텍처 스타일의 각 레이어는 아키텍처 내부에서 특정한 역할과 임무를 수행한다. 프레젠테이션 레이어는 모든 유저 인터페이스와 브라우저 통신 로직을, 비지니스 레이어는 요청을 받아 알맞은 비지니스 규칙을 실행하는 일을 한다.

이러한 관심사의 분리 개념 덕분에 레이어드 아키텍처 스타일은 아키텍처 내부의 역할 및 책임 모델을 효과적으로 구성할 수 있다. 각 레이어의 컴포넌트는 각 로직만 처리하여 개발자 본인의 기술 역량을 도메인의 (프레젠테이션 로직, 퍼시스턴스 로직 등의) 기술적인 부분에 집중시킬 수 있지만, 그런 장점을 대가로 전체적인 민첩성(변화에 신속학세 반응하는 능력)이 떨어지는 트레이드 오프가 있다.

레이어든 아키텍처는 기술 분할된 아키텍처이다. 즉, 컴포넌트를 도메인 단위로 묶는게 아니라, 아키텍처의 기술 역할에 따라 묶기 때문에 비지니스 도메인이 각각 모든 아키텍처 레이어에 분산된다. 예를 들어, 고객 도메인은 프레젠테이션, 비지니스, 규칙, 서비스, 데이터베이스 모든 레이어에 다 포함되므로 이 도메인에 어떤 변경을 가하는 일이 쉽지 않다. 이런 이유로 이런 아키텍처 스타일은 도메인 주도 설계 방식과는 잘 맞지 않다.

10.2 레이어 격리

레이어드 아키텍처의 각 레이어는 폐쇄(closed) 또는 개방(open) 상태입니다. 폐쇄 레이어란, 요청이 상위 레이어에서 하위 레어어로 이동하므로 중간의 어떤 레이어도 건너뛸 수 없고 현재 레이어를 거쳐야 바로 그 다음 레이어로 나아갈 수 있다는 뜻이다. 예를 들어, 프레젠테이션 레이어에서 시작된 요청은 일단 비지니스 레이어로 들어간 후, 퍼시스턴스 레이어를 거쳐 제일 마지막에 데이터베이스 레이어에 도달한다.

레이어 격리는 어느 아키텍처 레이어에서 변경이 일어나도 다른 레이어에 있는 컴포넌트에 아무런 영향을 끼치지 않기에 레이어 간 계약은 불변임을 의미한다. 각 레이어는 서로 독립적으로 작동되므로 다른 레이어의 내부 작동 로직은 거의/전혀 알지 못한다. 레이어 격리를 지원하려면 요청의 메인 흐름에 관한 레이어가 반드시 폐쇄되어 있어야 한다.

레이어를 격리하면 아키텍처의 모든 레이어를 (잘 정의된 계약과 비지니스 위임 패턴을 사용한다는 가정 하에) 다른 레이어에 영향을 주지 않고 교체할 수 있다.

10.3 레이어 추가

아키텍처 내부적으로 폐쇄 레이어를 이용해 변경을 격리할 수 있지만, 어떤 레이어는 개방하는 것이 더 합리적인 경우도 있다. 예를 들어, 비지니스 레이어에 (날짜, 문자열 유틸리티 클래스 등) 공통 비지니스 기능이 구현된 객체를 구현하여 공유하고, 프레젠테이션 레이어에서는 이 공유 객체를 직접 사용할 수 없도록 아키텍처 결정을 했다고 하자.

제약조건을 아키텍처적으로 강제하려면 공유 비지니스 객체가 모두 퐇마된 새로운 서비스 레이어를 아키텍처에 추가하면 된다. 서비스 레이어를 개방 레이어로 만들어 추가하면 비지니스 레이어는 이 레이어를 엑세스하거나 이 레이어를 지나쳐 다음 레이어로 향할 수 있다.

개방/폐쇄 레이어 개념을 잘 활용하면 아키텍처 레이어 간 관계와 요청 흐름을 정의할 때 유용하다. 또 개발자에게 아키텍처 내부의 다양한 레이어 액세스 제약에 관한 필수 정보와 지침을 제공할 수 있다. 아키텍처의 어느 레이어가 개방/폐쇄되어 있는지 정확히 문서화하여 소통하지 않으면 테스트, 유지 보수, 배포 작업이 아주 힘든, 단단히 커플링되어 금방이라도 깨질 듯한 아키텍처가 되어버릴 것이다.

10.4 기타 고려 사항

아직 아키텍처 스타일을 완전히 결정하지 못했다면 대부분의 애플리케이션에서 레이어드 아키텍처는 좋은 출발점이 될 것이다.

재사용은 최소한으로, 객체 계층은 최대한 가볍게 맞추어 적절한 모듈성을 유지하는 것이 중요하다. 그러면 나중에 다른 아키텍처 스타일로 갈아타더라도 큰 어려움이 없다.

레이어드 아키텍처에서는 아키텍처 싱크홀 안티패턴을 조심해야 한다. 요청이 한 레이어에서 다른 레이어로 이동할 때 각 레이어가 아무 비지니스 로직도 처리하지 않고 그냥 통과시키는 안티패턴을 말한다.

아키텍처 싱크홀 안티패턴에 해당하는 시나리오가 전무한 레이어드 아키텍처는 아마 하나도 없을 것이다. 안티패턴으로 처리 중인 요칭의 비율을 따져서, 전체 요청의 80%가 싱크홀이라면 이 문제 도메인에 레이어드 아키텍처는 적합한 아키텍처 스타일이 아니라는 증거이다. 아키텍처 싱크홀 안티패턴을 해결하는 또 다른 방법은 아키텍처의 모든 레이어를 개방하는 것이다. 그러나 이는 아키텍처상 변경 관리의 어려움이 가중되는 트레이드오프가 있음을 분명하게 인식해야 한다.

10.5 왜 이 아키텍처 스타일을 사용하는가

레이어드 아키텍처는 작고 단순한 애플리케이션이나 웹사이트에 알맞은 아키텍처 스타일이다. 특히, 처음 구축을 시작할 때, 예산과 일정이 빠듯한 경우 출발점으로 괜찮은 아키텍처 선택이다. 개발자, 아키텍트 모두 익숙하고 그리 복잡하지 않으며 어쩌면 비용도 가장 저렴한 아키텍처 스타일이므로 소규모 애플리케이션을 간편하게 개발할 수 있다.

레이어드 아키텍처 기반의 애플리케이션은 규모가 커질수록 유지 보수성, 민첩성, 시험성, 배포성 같은 아키텍처 특성이 점점 나빠진다. 따라서 레이어드 아키텍처를 사용한 대규모 애플리케이션이나 시스템은 다른 더 모듈러한 아키텍처 스타일이 더 잘 맞다.

10.6 아키텍처 특성 등급