Architecture | Layered Architecture

yeonk·2023년 4월 23일
0
post-thumbnail

Layered Architecture


프로젝트 구조는 presentation, application, domain, infrastructure 등 N가지 유형으로 분류할 수 있다.
이 때 각 유형을 레이어라고 하며, 전체 아키텍처를 레이어 아키텍처 또는 계층화 아키텍처라고 한다.

각 계층은 애플리케이션 내에서 특정 역할과 책임을 가지며, 특정 비즈니스 요청을 충족하기 위해 수행해야 하는 작업을 중심으로 추상화를 형성한다.

예를 들어, 프레젠테이션 계층은 모든 사용자 인터페이스 및 브라우저 통신 로직을 처리한다. 해당 계층은 데이터를 가져오는 방법에 대해 신경쓰지 않고, 해당 정보를 특정 형식으로 화면에 표시하기만 하면 된다.

반면, 비즈니스 계층은 요청과 관련된 특정 비즈니스 규칙을 실행하는 역할을 담당한다. 해당 계층은 화면에 표시되는 데이터 형식이나 데이터의 출처에 대해 신경 쓸 필요가 없으며, 데이터를 가져와 비즈니스 로직을 수행한 다음 전달하기만 하면 된다.





4-Tier Layered Architecture

반드시 있어야 하는 계층의 수와 유형이 명시되어 있지는 않지만 대부분의 계층형 아키텍처는 presentation, business, persistence, database로 4개의 표준 계층으로 구성되며, 규모에 따라 3개 혹은 5개 이상의 레이어로 구성할 수 있다.

출처: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html
  • Presentation Layer: 소프트웨어 시스템과의 사용자 상호 작용을 담당

  • Application/Business Layer: 기능적 요구 사항 수행과 관련된 측면을 처리

  • Domain Layer: 알고리즘 및 프로그래밍 구성 요소 담당

  • Infrastructure/Persistence/Database Layer: 데이터, 데이터베이스 처리 담당





특징


관심사 분리

계층형 아키텍처의 특징 중 하나는 컴포넌트 간의 관심사를 분리하는 것이다.
특정 계층 내의 컴포넌트는 해당 계층과 관련된 로직만 처리한다.

  • 아키텍처에 효과적인 역할과 책임 모델을 쉽게 구축할 수 있다.

  • 잘 정의된 컴포넌트 인터페이스와 제한된 컴포넌트 범위로 인해 애플리케이션을 쉽게 개발, 테스트, 관리 및 유지 관리할 수 있다.





격리된 레이어(layers of isolation)

폐쇄형 레이어(closed layer): 요청이 레이어에서 다른 레이어로 이동할 때 그 바로 아래 레이어를 통과해야만 그 아래 다음 레이어로 이동할 수 있음을 의미한다.
격리 계층(layers of isolation): 아키텍처의 한 계층에서 변경한 내용이 다른 계층의 구성 요소에 영향을 주지 않고, 해당 계층 내의 구성 요소와 다른 관련 계층에만 변경 내용이 격리된다는 것을 의미한다.

출처: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html



  • 각 계층이 다른 계층과 독립적이면 아키텍처에서 다른 계층의 내부 작동에 대한 정보가 적다는 것을 의미한다.

  • 만약 계층을 격리하지 않는다면 구성 요소 간에 많은 상호 의존성이 있는 매우 긴밀하게 결합된 애플리케이션이 만들어진다. 그렇게 되면 아키텍쳐를 변경하기 어렵고, 비용이 많이 들게 된다.
    예를 들면, presentation 계층이 persistence에 직접 액세스할 수 있도록 하면 persistence 계층 내에서 SQL을 변경하면 비즈니스 계층과 프레젠테이션 계층 모두에 영향을 미칠 수 있다.





적용 예시


계층화된 아키텍처가 어떻게 작동하는지 그림을 통해 알아보자.
해당 그림은 특정 개인에 대한 고객 정보를 검색하려는 비즈니스 사용자의 요청에 대한 작동의 예이다.

출처: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html
  1. customer screen(사용자 화면, view)에서 고객 정보를 요청한다.

    • 데이터 위치, 검색 방법, 쿼리에 대한 정보는 알지 못 한다.

    • customer screen은 고객 정보를 표시할 책임이 있다.

  1. customer screen에서 특정 고객 정보를 요청을 받으면, 해당 요청을 customer delegate(controller)로 전달한다.

    • customer delegate는 business 계층에서 해당 요청을 처리할 수 있는 모듈과 해당 모듈에 도달하는 방법, 필요한 데이터를 파악하는 역할한다.
  1. business 계층의 customer object는 비즈니스 요청에 필요한 모든 정보를 집계하는 역할을 한다.

    • persistence 계층의 customer DAO를 호출하여 고객 데이터를 가져오고, order DAO를 호출하여 주문 정보를 가져온다.
  1. persistence 계층의 DAO는 차례로 SQL 문을 실행하여, database 계층에 접근하여 데이터를 검색한 후 business 계층의 customer object로 다시 전달한다.

    • business 계층의 customer object가 데이터를 받으면 데이터를 집계하여 해당 정보를 customer delegate로 다시 전달하고, customer delegate는 해당 데이터를 표시할 customer screen으로 전달한다.





고려 사항


싱크홀 안티 패턴(architecture sinkhole anti-pattern)

요청이 아키텍처의 여러 계층을 통과하는 상황에서 각 계층 내에서 로직이 거의 수행되지 않고, 단순히 통과하는 것(하위 레이어로 전달하는 것)을 말한다.

  • 싱크홀 안티 패턴 발생 여부를 판단할 수 있는 방법으로 80-20 rule 이 있다.

    • 요청의 약 20%가 단순 통과 처리이고, 요청과 관련된 비즈니스 로직이 80%인 것은 일반적이다.

    • 이 비율이 역전된 경우에는 계층 격리가 없기 때문에 변경을 제어하기가 더 어려워질 수 있기 때문에 일부 아키텍처 계층을 open하는 것을 고려해볼 수 있다.



모놀리식 애플리케이션(Monolithic Application, MA)

계층형 아키텍처는 모놀리식 애플리케이션에서 사용되는 경향이 있기 때문에 모놀리식 애플리케이션의 단점 역시 고려해야한다.

  • 프레젠테이션 계층과 비즈니스 계층을 배포 가능한 단위로 분할하더라도 모놀리식 애플리케이션에 적합한 경향이 있다. 일부 애플리케이션에서는 문제가 되지 않을 수 있지만 배포, 일반적인 견고성 및 안정성, 성능 및 확장성 측면에서 몇 가지 잠재적인 문제를 야기할 수 있다.





결론


계층형 아키텍처의 장단점을 고려하여, 개발하고자 하는 애플리케이션에 적절할지 판단한다.
사용 시, 싱크홀 안티 패턴과 모놀리식 애플리케이션의 특징도 함께 고려해본다.

장점

  • 각 레이어의 기능이 다른 레이어와 분리되어 있기 때문에 의존성이 적다.

  • 각 레이어가 독립적이기 때문에 테스트가 쉽고 개별 테스트가 가능하다.



단점

  • 확장이 어려운 구조이다.

  • 유지 관리가 어려울 수 있다. 단일 계층의 변경이 전체 시스템에 영향을 미칠 수 있다.

  • 데이터를 수신하기 위해 상위 레이어에 의존하기 때문에 레이어 간 상호 의존성이 있다.



언제 사용하면 좋을까?

빠르게 구축해야 하는 애플리케이션을 개발하는 경우, 확장성보다 일관성이 중요한 경우, 개발자가 소프트웨어 아키텍처에 대한 지식이 많지 않거나 어떤 아키텍처를 사용할지 결정하지 못한 경우에 사용하면 좋을 수 있다.





참고 자료


Chapter 1. Layered Architecture

educba - Layered Architecture

baeldung - Layered Architecture

모놀리식 vs 마이크로서비스, 어떤 아키텍처를 선택할까?

Layered Architecture Deep Dive

0개의 댓글