최근에 프로젝트를 계속 하면서 생각이 많이 드는 것이 아키텍처와 OOP에 대한 생각이다.
필자는 사실 학교에서말고 지금까지 OOP를 다뤄본적이 없었다. 하지만 이번에 프로젝트를 NestJS로 개발해보면서 OOP의 개념이 필요해지기 시작했고, 아키텍처 부분에 관심이 생기기 시작했고 클린코드에도 관심이 생겨서 차근차근 공부하고 있다.
오늘은 Layered Architecture가 무엇을 의미하는지, 장점은 무엇인지 등에 대해 정리해보려고 한다.
계층형 아키텍처란?
소프트웨어 개발에서 가장 일반적으로 널리 사용되고 있는 아키텍처이다. 그리고 소스코드의 역할과 관심사에 따라 이를 계층으로 분리한 아키텍처이다.
각 계층은 어플리케이션 내에서의 특정 역할과 관심사(화면 표시, 비즈니스 로직 수행 및 DB작업 등) 별로 구분된다. 이것은 Layered Architecture의 강력한 기능인 관심사의 분리를 의미한다.
특정 계층의 구성요소는 해당 계층에 관련된 기능만 수행하고, 이런 특징은 높은 유지보수성과 쉬운 테스트라는 장점이 있다.
4-Tier Layered Architecture (N-tier)
보통 구성되는 계층의 숫자에 따라 N-Tier Architecture 라고도 한다. 하지만 일반적인 경우 4개의 레이어로 구분하고 있다.
하지만 이거는 케바케이다. 만약에 단순한 어플리케이션이면 3개의 계층으로 나뉠수도 있고 복잡한 어플리케이션이라면 5개 또는 그 이상으로도 충분히 될 수 있다고 생각하면 된다.
(1) Presentation Layer
사용자와의 요청 및 응답 등 상호작용 처리에 관심사를 둔 계층입니다. 비즈니스 로직이 어떻게 수행되는지는 알 필요가 없다. 대표적인 구성요소는 View와 Controller가 있다.
(2) Business Layer (Domain Layer)
비즈니스 로직을 수행하는 것을 주 관심사로 가져간다. 다시말해서 화면에 데이터를 출력하는 방법이나 데이터를 어디서 어떻게 가져오는지에 대한 내용은 관심이 없다.
Persistence Layer에서 데이터를 가져와서 비즈니스 로직을 수행하고 그 결과를 Presentation Layer로 전달하면 된다. 대표적인 구성요소는 Service와 Domain Model이 있다.
필자는 Business Layer 뒤에 괄호치고 Domain Layer라고 작성을 했는데 실제로 경우에 따라 Service와 Domain Model을 별개의 계층으로 나누거나 아예 Domain Model을 Layered Architecture와 별개로 분리하는 경우도 있다고 한다.
(3) Persistence Layer (Data Access Layer)
데이터베이스에 직접적으로 요청을 전달하는 등 데이터베이스에 접근하는데 관심사를 둔 계층이다. 다시말해 데이터베이스와 매핑되는 객체로서의 엔티티를 영구히 관리하는 계층이라고 할 수 있다. 대표적인 구성요소로는 ORM, Repository, DAO가 있을 수 있다.
(4) Database Layer
실제 데이터베이스 서버가 운영되는 계층이다. 서비스에서 사용하고 있는 DB가 이 계층에 속할 수 있다.
Layered Architecture의 특징
각 계층은 다른 계층들과의 낮은 결합도를 가지고 내부적으로는 높은 응집도를 가질 것을 지향하고 있다.
결국 계층을 분리한 가장 큰 이유는 코드 가독성과 유지보수의 용이성을 극대화할 수 있기 때문이라고 할 수 있을 것 같다.
Layered Architecture의 장점과 단점
장점
- 계층별 관심사가 분리되기 때문에 코드 가독성과 유지 보수성이 높다.
- 모듈 교체가 용이하다. (다른 계층에 미칠 부수효과가 현저히 작을 것!)
- 테스트 하기에 용이하다. (의존관계가 없기 때문에!)
단점
실제로 계층형 아키텍처는 도메인의 관점에서 문제가 있다고들 한다.
계층형 아키텍처 구조에 따라 소프트웨어가 핵심적으로 해결하고자 하는 문제영역으로서 도메인이 아니라 Data-Access 계층, 즉 DB가 소프트웨어의 핵심이 될 수 밖에 없다.
다른 개발자님의 블로그를 확인해보니 계층형 아키텍처의 최하단 계층이 DB단이기 때문이라고 생각할 수 있을 것 같다.
위에서 언급했듯이 Layered Architecture의 일반적인 구조는 다음과 같다.
Presentation => Business(Service / domain) => Persistence(Data-Access) => DB
결론적으로 DB에서 Column이 추가 또는 삭제되거나 DB가 다른 DBMS로 변경되는 등 DB 계층에서의 변경사항이 Business Layer에 영향을 미칠 수 밖에 없다는 것이다. (프로젝트 하면서 많이 공감함)
물론 Presentation 계층은 Business 계층에 의해서 영향을 받을 수 밖에 없다. 하지만 중점은 도메인이 DB에 영향을 받는다는 것이다.
- 소프트웨어가 해결하고자 하는 핵심은 도메인이고, DB와 프레임워크 등은 그 도메인을 수행하기 위한 기반 환경들인데, 도메인이 DB에 영향을 받는 것은 옳지 않다.
- 또한 DB가 아키텍처의 메인이 되면 아키텍처를 유지 및 보수 또는 확장하는 과정에서 Persistence 계층과 Domain 계층의 구분이 모호해지는 지점이 발생할 수 있다. (ORM?)
- 따라서 Layered Architecture의 특징이 사라질 수 있다는 것이다.
그래서 위와 같은 문제점들을 의존성 역전을 활용해서 해결할 수 있다고 한다. 클린 아키텍처가 의존성 역전을 활용해서 계층형 아키텍처의 문제점을 해결하는 방식을 정립한 아키텍처라고도 한다.
클린 아키텍처에 대해서는 추가적으로 공부하고 정리해보도록 하겠다.
추가 정보들
Layered Architecture에서 나뉘어진 계층은 수직적으로 배치가 된다. 특정 레이어는 바로 하위 레이어에만 연결된다는 것이다.
만약에 Presentation Layer에서 바로 Database Layer에 연결해서 정보를 가져오는 건 어떨까? 실제로 내가 동아리에서 아무것도 모르고 개발할 때는 이렇게 했었다. Controller에서 바로 Database Layer로 내려가서 데이터를 가져오는 식으로 코드를 작성한 적이 있었다.
물론 이게 편하긴 하다. 하지만 Presentation Layer에서 직접 DB에 접속해서 데이터를 가져오게 되면 SQL에 대한 변경사항이 Presentation Layer에 바로 영향을 미치게 되는 것이다. 즉, 과도한 의존성이 발생하게 되는 것이다. 하지만 이게 어플리케이션의 변경을 매우 어렵게 만든다는 것이다.
Layered Architecture에서 각 레이어는 캡슐화 되어있다. 각 레이어가 다른 레이어와 독립적이기 때문에 특정 레이어는 다른 레이어의 내부 동작을 모르게 된다. 따라서 특정 레이어는 다른 레이어에 영향을 주지않고 변경될 수 있다.
느낀점
이렇게 Layered Architecture에 대해서 조금 자세하게 알아봤다. 원래 대충 수박 겉핥기식으로 알고 있긴 했지만 이렇게 자세하게 알고있진 몰랐고 프로젝트하면서 느꼈던 답답함이 Layered Architecture의 단점이었다는 걸 알게 되었다.
Reference
