220812 TIL Layered Architecture란 무엇인가?

오늘 아침에 어제 제출한 과제에 대한 코드 리뷰를 확인하는데 멘붕이 왔다. 

생각보다 많은 부분이 잘못되었다는 것과 이것을 수정하기 위해서 코드 전체적인 구조 자체를 바꿔야 할 것 같다는 생각이 들었기 때문이다.

repositroy의 변수를 service에서 직접적으로 건드리고 있었고, controller에서 repository에 바로 접근하고, repository가 해야할 역할을 service가 하고 있는 등 잘못된 코드가 한 두 개가 아니었다.

 

일단 repository와 service 각각의 역할을 제대로 파악하지 못했기 때문에 일어난 일인 것 같다.

그래서 각 계층이 무슨 역할을 하는지 알기 위해 Layered Architecture에 대해서 공부해봤다.

 

Layered Architecture란?

계층화 아키텍처(Layered Architecture)는 소프트 웨어 개발에서 가장 일반적으로 사용되고 있는 아키텍쳐 패턴이다

각각의 계층은 계층마다의 역할별로 구분이 된다. 특정 계층의 구성요소는 해당 계층에 관련된 기능만 수행하기 때문에 관심사의 분리가 아주 잘 되어있다.

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
  • 대표적으로 View와 Controller가 이 계층에 해당한다.
  • 이 계층은 client의 요청을 받고 응답하는 계층이다.
  • 이 계층의 특징은 어떻게 client의 요청을 처리할 것인지는 관심이 없다. 그저 요청을 어떻게 받고 응답을 어떻게 할지에 대해 관심이 있는 계층이다. 요청에 대한 처리는 Business layer로 전달한다.

• Business Layer
  • 대표적으로 Service가 이 계층에 해당한다.
  • 비즈니스 로직을 담당하는 계층이다.
  • 프레젠테이션 계층이 client의 요청을 받아오면 Business는 실제 요청에 대한 처리를 하는 부분이다. client가 웹이던 앱이던 혹은 database를 어떤 것을 사용하는지 관심 없다. 그저 비지니스 로직을 처리하는 부분이다.
• Persistence Layer
  • 대표적으로 Repository가 이 계층에 해당한다.
  • 데이터 베이스에 접근하는 계층이다.
  • Business의 요청 처리에 따라 데이터베이스에서 데이터를 저장하거나 조회하거나 삭제하는 등의 로직을 수행한다.
• Database Layer
  • 위 계층에서 처리된 데이터를 저장하고 관리하는 계층이다. (MySQL, MariaDB, PostgreSQL, MongoDB 등 데이터베이스가 위치함)

 

Layered Architecture의 특징

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

• 각 계층마다 역할과 책임이 나누어진다.
• 요청 순은 Presentation -> Business -> Persistence -> Databse 순서로 호출이 된다.
• 이렇게 계층이 수직적으로  배치된 것이 Layered Architecture의 주요 특징 중 하나이다. 
• 특정 레이어는 바로 하위 레이어에만 연결된다.

 

그림을 보면 각각의 계층은 closed 되어 있다. 이 부분이 layered architecture의 가장 중요한 특징이다.

각각의 계층은 요청할 때 2단계 이상의 계층으로 넘어갈 수 없고 순차적으로 바로 아래의 계층을 지나가면서 이동해야 한다.

예를 들어 Presentation Layer가 Database Layer에 바로 접근하지 말고, Business Layer계층을 거치고 Persistence Layer 계층을 거친 다음 Database Layer로 이동해야 한다.

 

왜?

굳이 계층을 하나씩 거치지 말고 그냥 Presentation 계층이 바로 Database 계층에 접근하는 게 database의 정보를 가져오는 게 더 빠르고 편하지 않을까? 하는 생각이 든다.

 

이에 대한 답은 각각의 계층은 격리되어있어 각 레이어가 독립적이라는 데서 얻을 수 있다.

레이어 격리 개념은 아키텍처의 한 레이어에서 일어난 변경 사항이 다른 레이어에 영향을 미치지 않는다는 것을 말한다.

즉 각 계층은 캡슐화되어 있고, 단일 책임을 갖는다. 

 

만일 presentation 계층이 database 계층에 바로 접근을 허용하면 database에서 일어난 변경사항들이  Business, Persistence 계층에 모두 영향을 미치게 되는 일이 발생한다. 

그러면 계층 간 과도한 의존성이 발생이 되고, 과도한 의존성의 문제는 코드 유지보수가 매우 어려워진다.

 

이거 바꾸면 저것도 바꿔야 하는 등 코드를 변경하기가 아주 복잡해진다.

 

 

Layered Architecture의 장점

• 만일 이렇게 계층이 나눠져 있지 않다면 요청받고, 응답하고, 처리하고 저장하는 작업이 모두 한 곳에서 이루어져 할 것이다. 그러면 코드가 복잡해지고 유지보수가 매우 어려워진다.
• 즉 각각의 계층을 독립적으로 나눠서 자신의 관심사에만 집중하게 함으로써 유지보수 하기가 더 쉽다.
• 각 계층은 독립적이기 때문에 하위계층의 변경에 있어서 상위계층은 신경 쓰지 않아도 되기 때문에 각 계층 간의 역할이 명확해지고, 각 계층별로 테스트하기 매우 용이하다.

 

 

 

이렇게 각 계층의 역할에 대해 정리를 하고 나니까 service와 repository의 역할에 대해서 명확해 졌고, 왜 controller에서 repository가 보이면 안된다고 하셨는지 이해가 됬다.

 

controller가 view에 보여줘야할 데이터는 repositroy에서 바로 꺼내오는게 아니라 service가 repository에 접근해서 데이터를 받아오고 받아온 데이터는 service에서 로직을 거쳐서 그 값을 controller에 전달해서 controller는 view에게 그 값을 전달해주는 서로 각자의 역할만 하는 구조인것 같다.

 

 

참고

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

Software Architecture Patterns