레이어드 아키텍처

레이어드 아키텍처는 가장 흔한 아키텍처 스타일로 모놀리식 아키텍처 중 하나이다.

단순하고 대중적이며 비용도 적게들어서 사실상 표준 아키텍처이다.

 

레이어 분리

• 내부 컴포넌트는 논리적으로 수평한 레이어들로 구성된다.
• 각 레이어는 애플리케이션에서 프레젠테이션 로직, 비즈니스 로직 등의 주어진 역할을 수행한다.
• 일반적으로 프레젠테이션, 비즈니스, 퍼시스턴스, 데이터베이스 4개의 표준 레이어로 구성한다.
• 물론 규모에 따라 병합하기도 하고, 그 이상의 레이어를 구성하기도 한다.

1. Presentation Layer

• 사용자 혹은 클라이어느 시스템과 직접적으로 연결되는 부분이다.
• 이 외 비즈니스 로직은 해당 계층의 관심사가 아니다.

2. Business Layer

• 비즈니스 로직을 구현하는 부분이다. 실제로 시스템이 구현해야 하는 핵심 로직을 담당하고 있다.
• Presentation Layer로 부터, 사용자의 요청을 전달 받고 해당 요청을 실질적으로 처리하는 부분이다.

3. Presistence Layer

• 데이터의 영구 저장과 관리를 담당하는 부분이다.
• 웹 어플리케이션과 데이터베이스와 상호작용을 처리하며, 데이터베이스와의 상호작용을 추상화한다.

4. Database Layer

• 실제 데이터베이스를 뜻한다.

관심사 분리

• 중요한 특징은 관심사의 분리이다.
• 예를 들어 비즈니스 레이어는 데이터를 어떻게 받아야 하는지, 화면은 어떻게 보여줄지 전혀 관여하지 않는다.
• 따라서 기술적인 부분에 집중할 수 있지만, 변화에 반응하는 능력(민첩성)은 떨어진다는 단점이 있다.
  
  

도메인 변경의 어려움

• 도메인 분할 아키텍처와 반대로 기술 역할에 따라 묶는다.
• 반대로 이야기 하면 어떤 도메인은 모든 레이어에 분산되게 한다. 따라서 이 도메인을 변경하는 것이 쉽지 않다.
• 예를 들면 '고객' 도메인을 변경하려면 프레젠테이션, 비즈니스, 서비스, 데이터베이스 등을 모두 변경해야 한다.
• 이런 이유로 레이어드 아키텍처 스타일은 도메인 주도 설계 방식과 잘 안 맞는다.
  
  

레이어 격리

• 각 레이어는 폐쇄(closed) 또는 개방(open) 상태이다.
• 폐쇄 레이어란 요청이 상위 레이어에서 하위 레이어로 이동하므로 중간에 어떤 레이어도 건너뛸 수 없다.
• 예를 들면 프레젠테이션이 퍼시스턴스 레이어에 직접 액세스한다고 하자, 
  그럼 퍼시스턴스 레이어에서의 변경이 발생하는 경우 비즈니스 레이어, 프레젠테이션 레이어 둘 다 영향을 받게 되고, 결국 컴포넌트간의 상호 의존도가 높아진다.
• 따라서 가능한 폐쇄 레이어로 설계하는게 유지 보수에 유리하다.
  
  

싱크홀 안티 패턴(architecture sinkhole)

• 아키텍처 싱크홀 안티 패턴을 조심해야 한다.
• 요청이 한 레이어에서 다른 레이어로 이동할 때 각 레이어가 아무 비즈니스 로직도 처리하지 않고 그냥 통과하는 것을 말한다.
• 이런 흐름은 불필요한 객체 초기화 및 처리를 빈번하게 유발하고 쓸데없이 메모리를 소모하며 성능에도 부정적인 영향을 준다.
• 물론 싱크홀 안티패턴이 없을 순 없다. 전체 요청의 20%가 싱크홀인 정도면 그런대로 괜찮은 수준이다.
  선택을 할 때 일반적으로 80-20 규칙을 따른다. 이는 요청 20%는 단순 통과 처리하고, 80%는 비즈니스 로직을 수행한다는 규칙이다.
  
  

레이어드 아키텍처를 사용하는 이유

• 작고 단순한 앱이나 웹 사이트에 알맞은 아키텍처이다. 
  특히, 처음 구축할 때 출발점으로 괜찮은 아키텍처 선택이다.
• 그리 복잡하지 않고, 어쩌면 비용도 가장 저렴한 아키텍처 스타일이므로 소규모 애플리케이션을 간편하게 개발할 수 있다.
• 물론 규모가 커질 수록 유지보수성, 민첩성, 시험성, 배포성 같은 특성이 점점 나빠진다.

 

장점

• 각 계층이 관심사별로 분리되어 있어, 코드의 재사용성과 유지보수성이 향상된다.
• 기능이 확장되거나 변경이 발생할 경우에 해당 계층의 코드만 변경이 된다. 즉, 변화에 유연하게 대처한다.
• 계층마다 독립적으로 테스트가 가능하므로, 단위 테스트나 통합 테스트가 용이하게 수행된다.

단점 

• 오버헤드 
  • 계층간 통신을 통해 동작하여, 데이터의 전달 및 변환 과정에서 일부 오버헤드가 발생한다.
    이는 계층이 많아질수록 더 증가한다.
• 복잡성
  • 계층간 통신을 위해 인터페이스와 로직을 추가해야하므로 복잡성이 증가한다.
    특히, 대규모 프로젝트에서는 계층간의 관리와 유지보수가 복잡해질 가능성이 크다.
    
    

개인 소감

레이어드 아키텍처를 조사하면서 가장 중요하게 봤던 부분이 관심사 분리였다.

최근에 프로젝트를 진행하면서 프레젠테이션 계층(controller)에서 데이터를 주고받거나 비즈니스 계층(service)을 호출하는 것 이외의 코드를 작성하였다.

이는 테스트 코드를 작성할 때 변수가 될만한 요인이 되어 값을 제어하기가 어려웠다.

그래서 각 계층의 주어진 역할만 수행하도록 코드를 작성하는게 중요하다고 생각한다.