레이어드 아키텍처 스타일 (Layered architecture, n-tiered architecture)

소프트웨어 아키텍처 101 - YES24

 

프레젠테이션(Presentation) 레이어

비즈니스(Business) 레이어

퍼시스턴스(Persistence) 레이어

데이터베이스(Database) 레이어

 

관심사의 분리 (separation of concerns)

모듈화와 인터페이스간의 연결에 대한 이야기로 표현할 수도 있는데, OSI 7계층처럼 각각의 영역이 담당하는 역할과 책임을 기준으로 만든다는 것이다.

따라서, 역할과 책임을 기준으로 레이어를 나누고 각 레이어별로 어떠한 인터페이스를 가지고 데이터를 주고 받을 것인지를 결정하여, 레이어별로 해당 역할과 책임에 대해서만 전념할 수 있도록 하는 것이다.

 

토폴로지 구성

레이어드 아키텍처를 사용할 때, 위 테이블처럼 하나의 토폴로지(묶음)로 구현/배포를 하는 것은 아니다.

예를 들어, 데이터베이스 레이어만 분리하여 2개의 토폴로지로도 가능하며, 프레젠테이션 레이어도 분리해서 3개의 토폴로지로도 가능하다.

중요한 것은 “역할과 책임”이라는 기준에 의해 레이어로 나누어져 있고, 각각은 추상화된 인터페이스로 접근하게 만드는 것이다.

 

기술 분할 아키텍쳐

레이어드 아키텍처는 기술 분할 아키텍처다.

즉, 반대되는 개념인 도메인 분할 아키텍처의 ‘도메인’ 입장에서 보았을 때, 각각의 도메인이 기술 레이어에 따라 레이어별로 나뉘어져서 구현될 수 있는 것이다.

따라서 도메인 주도적 설계가 필요한 상황에서는 추천되지 않는 방식이다.

 

레이어를 어떻게 구성할 것인가?

하위 레이어가 상위 레이어를 모르게 하라 - 계층구조(hierarchy) 문제

간단히 말해서, 하위 레이어에서 상위 레이어의 API를 콜하거나 상위 레이어가 가지고 있는 정보에 의존(dependency)하지 말라는 것이다.

즉, 하위 레이어는 인터페이스만 제공하여 상위 레이어에서 접근할 수 있게만 하는 것이지 상위 레이어를 알고 있어서는 안된다.

이렇게 레이어간의 격리를 잘 해두고, 상위 레이어로부터 하위 레이어로만 ‘요청’하는 형태로 간다면, 추후, 특정 레이어만 교체하는 것이 훨씬 수월해진다.

가능한 레이어를 관통하는 요청은 피하자 (But 더 나쁠 수 있는 싱크홀 안티 패턴)

좀 더 직관적으로 설명하면, 상위 레이어에서 인접한 하위레이어에 ‘요청’하는 것이 아니라 그보다 더 밑에 있는 (인접하지 않은) 하위레이어에 ‘요청’을 하는 경우를 뜻한다.

위의 표를 기준으로 설명하면, 프레젠테이션 레이어에서 퍼시스턴스나 데이터베이스 레이어에 다이렉트로 접근하는 것이다.

구현하는 환경 구성이나 요구 조건에 따라 성능과 같은 이유에 의하여 이러한 구현이 요구될 수 있는데, 아무래도 단일화된 원칙이 아니라 ‘예외’ 조건이 생기는 것이므로 이에 대해서는 정확한 문서화를 통해 관리하고 소통에 사용되어야만 한다. 그렇지 않으면, 매우 힘든 경험을 할 수 있을 것이다.

 

BUT!! 더 안 좋을 수 있는 싱크홀 패턴이라는 것이 있다.

싱크홀처럼 뚝 떨어지는 것을 의미하는데, 즉, 레이어를 만들어 뒀기 때문에 하위 레이어를 항상 거치지만 막상 그 레이어에서는 아무것도 안하고 그대로 통과시키는 것을 의미한다.

예를 들어, 프레젠테이션 레이어에서 데이터베이스의 정보를 가져오려고 하는데, 중간의 두 레이어에서는 아무것도 하지 않고 through pass 하는 경우이다.

그래서 중간의 두 레이어에서는 최소 function 두번이라는 불필요한 오버헤드가 발생하게 되는것이다.

그래서, 이처럼 싱크홀 안티패턴을 사용할바에는 하위 레이어들을 개방하여, 보다 상위 레이어에서 직접 call을 할 수 있게끔 하는 것이 좋을 수도 있다는 것이다.

물론, 그렇게 되면 앞서 말했던 부분과도 상충이되기때문에, 트레이드오프를 고려하여 선택하는 것이 가장 올바른 접근법이 될 것이다.

그리고 문서화를 잘 해두는 것이 중요하다.

 

아키텍처 특성

아키텍처 특성	별점
분할 유형	기술
퀀텀 수	1
배포성	★
탄력성	★
진화성	★
내고장성	★
모듈성	★
전체 비용	★★★★★
성능	★★
신뢰성	★★★
확장성	★
단순성	★★★★★
시험성	★★

 

어떤 경우에 사용하면 좋을까?

작고 단순한 어플리케이션에 알맞는 스타일이다.

특히, 임베디드 장치(MCU라면 더욱)의 경우 이 패턴을 쓰기에 용이하다.

애초에 물리적인 하드웨어와 그 하드웨어를 추상화시킨 레이어를 제공받아 사용하는 경우가 많기 때문에, 자연스럽게 이러한 레이어드 패턴으로 가게 되는 경향이 있다.

물론, 계속 이야기하는 것처럼, “요구사항”에 따라 더 나은 아키텍처가 존재하므로 위에서 언급한 곳에서 레이어드 아키텍처를 쓰는게 가장 좋다! 라고 생각하는 잘못된 일반화에 빠지지 않길 바란다.