스프링 공부를 하면서 그냥 이렇게 하는구나~ 정도로만 알고 있었던 계층형 아키텍처(Layered Architecture)가 무엇인지, 그리고 왜 사용하는지에 대해 알아보자.
계층형 아키텍처란?
계층형 아키텍처는 소프트웨어 개발에서 일반적이고 널리 사용되는 아키텍처이다. 계층형 아키텍처는 일반적으로 Presentation Layer, Business Layer, Persistence Layer, Database Layer, 총 4가지의 계층으로 나뉜다. 꼭 4가지로 나뉘어야 한다는 규칙은 없으나, 아래의 사진과 같이 4가지의 계층으로 나뉘는 것이 가장 보편적인 방법이다. 분리된 계층의 수에 따라서 n-tier-architecutre라고 칭하기도 한다!
Presentation Layer (UI Layer, Controller, View)
주로 사용자/유저와 소프트웨어 간의 상호작용을 처리하는 계층이다. 유저의 시각에서 가장 직관적인 계층이며 소프트웨어의 최종 목적을 충실하게 수행하는 계층이라고 할 수 있겠다. 사용자와의 상호작용을 담당하는 계층인 만큼 UI Layer, Controller, View 등으로 불리기도 한다.
HTTP 요청 파라미터, HTTP 바디 검증을 수행하고 클라이언트의 요청을 받고 응답을 보내는 역할을 수행한다.
Application Layer (Business Layer)
시스템의 핵심이 되는 메인 프로그램을 담당하는 계층이다. 비즈니스 로직을 처리하고, Presentation Layer에서 받은 요청을 해석하고 해당하는 기능을 수행한다. 즉, 시스템의 목적과 기능을 실제로 구현하는 계층이다! 위의 사진 자료에는 Business Layer라고 표기되어 있지만, 검색해 보니 Application Layer로 칭하는 경우가 더 많은 것을 알 수 있다. 아무래도 비즈니스 로직처리를 담당해서 그렇게 부르기도 하는 듯하다.
해당 계층에서 비즈니스 로직 처리(주문 처리, 결제처리와 같은), 예외 처리를 통한 에러 대응, 비동기 이벤트 처리와 같은 비즈니스 로직, 핵심 기능과 관련된 일들을 처리한다!
Domain Layer (Model Layer)
시스템의 핵심 개념, 규칙 등을 표현하고 구현하는 계층이다. 엔티티와 값 객체, 비즈니스 규칙 등의 정보, 개념이 위치하는 계층이 바로 Domain Layer인 것이다. Business Layer, Model Layer라고 부르기도 한다. DTO, VO와 같은 데이터 객체들이 해당 계층에 포함된다!
Infrastructure Layer (Persistence Layer)
마지막 계층인 Database Layer와 직접적인 관계를 갖는 계층이다. 주로 데이터베이스와의 직접적 상호작용을 처리한다. 대표적인 예로는 CRUD를 통한 데이터 제공 및 관리 역할 수행이 있다! 혼용어로는 Persistence Layer가 있다.
조사를 하면서 각각 용어가 많이 다르고, 같은 계층형 아키텍처이지만 다른 구조라 적잖이 당황스러웠다.
헤매다 내린 결론은... Presentation 계층이니, Application 계층이니 하는 용어와 해당 계층이 포함하는 기능/개념이 중요한 것이 아니라, 본인의 서비스에 효율적이고 적합한 형태의 Layered Architecture를 적용하는 것이다. 본인의 서비스에 적용했을 때 가장 효율적인 아키텍처가 곧 최적의 아키텍처인 셈이다! 애초에 n-tier Architecture라고 부르는 데에는 이유가 다 있는 것이다!
그래서 왜 사용하는 것일까?
계층형 아키텍처의 핵심은 소프트웨어의 시스템을 기능과 역할에 따라 서로 다른 계층으로 분리하여 구성하는 것이다. 이렇게 계층으로 분리함으로써 각 계층은 독립성을 가지게 되며, 이는 계층 간 결합도를 낮추고 응집도를 높이는 데에 도움이 된다.
각각의 다른 목적을 지니는 코드들이 분리 없이 한 곳에 작성되어 있다고 생각해 보자. 한 곳에서 코드를 관리하게 되면 복잡해질 뿐만 아니라 수정사항이 발생할 경우, 해당 코드와 연관된 모든 코드를 수정해야 할 수도 있고 최악의 상황에는 시스템 전체를 뜯어고쳐야 하는 불상사가 발생할 수도 있다.
실생활에서 겨울옷은 겨울옷장 칸, 여름옷은 여름옷장 칸에 넣는 것처럼 비슷한 목적, 성질을 지니는 코드를 한 곳에서 관리하고 자기보다 아래의 계층과만 의존성을 맺어주어 관리한다면 관리, 효율 측면에서 훨씬 좋지 않을까?
참고자료
https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html
https://priyalwalpita.medium.com/software-architecture-patterns-layered-architecture-a3b89b71a057
