Layered Architecture

 

선정 이유

 

공부한 책

 

 이번년도 1학기때 스프링 프레임워크에 대한 강의를 들었었다. 당시에 '스프링 부트와 aws로 혼자 구현하는 웹 서비스' 라는 책으로 공부를 했었는데 거기서 소개된 내용중에 Layered Architecture가 있었다. 설계 패턴중에 하나인데 이 패턴대로 따라간다면 유지보수하기가 굉장히 편해보였다. 그리고 뭔가 이제까지 주먹구구로 개발하는것과는 달리 어떠한 기준을 세우고 개발을 한다는 것에 매력을 느꼈다. 

 

 그래서 이번의 개발 프로젝트에서도 Layered Architecture 패턴을 적용하기로 마음먹었고 이미 사라져버린 기억들도 되살릴 겸 자료조사를 진행했다.

 

 

---

 

Layered Architecture란?

 

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

 

 

1. Java EE 애플리케이션에서 자주 볼 수 있는 아키텍쳐 패턴이다.

2. n-tier 아키텍쳐 패턴으로도 알려져있다.

3. 애플리케이션의 각 계층은 애플리케이션 내에서 특정한 역할을 맡는다.

 

 

각 계층의 기능

1. 프레젠테이션 계층은 모든 사용자 인터페이스와 브라우저간 통신을 처리한다.

2. 비즈니스 계층은 요청과 관련된 특정 비즈니스 규칙을 실행하는 책임을 진다.

3. Persistence 계층은 데이터를 가져와 비즈니스 업무를 처리한다.

 

* 가장 큰 장점은 '관심의 분리'로 아키텍쳐에 효과적인 모델과 책임 모델을 쉽게 구축 할 수 있도록 한다.

 

 

 

 

특징

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

1.  각 계층은 'CLOSED' 즉 닫힌것으로 표기된다.

2. 이는 계층간 이동 시 순차적으로만 계층 이동이 가능하다는 뜻이다.

3. 예를 들어 프레젠테이션 계층에서 시작된 요청은 비즈니스 계층을 거쳐 Persistence 계층으로 이동해야 한다.

 

 

* 하지만 계층간 순차적으로 이동하고 Jump를 수행해야 하는 경우도 있다. 대표적으로 다음과 같은 경우가 있다.

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

 

기존에 Service 계층을 가지고 있지 않다가, 새로운 기능을 확장하면서 Service 계층을 만들었다고 생각해보자. 이렇게 아키텍쳐가 바뀌고, 바뀐 아키텍쳐 패턴에 맞추려면 기존에 Business 레이어에 있는 기능들을 전부 서비스 계층을 통과해서 Persistence 계층으로 접근하도록 전부 코드를 바꿔야할까? 

 

그럴 필요 없이 Service 계층의 상태를 OPEN으로 변경하면, Business 계층에서 Persistence 계층에 바로 접근이 가능하니 이런식으로 해결하면 된다.

 

---

 

기존에 스프링에서는 사용해봤는데, 이번에 프론트로 사용하려는 React에서 사용해본적이 없어서 어찌 적용해야할지 좀 막막한 부분이 없잖아 있다. 기존 프로젝트들은 이 패턴을 어떤식으로 사용하고 있는지 확인해보고 연습해봐야겠다.

 

 

 

---

Reference

 

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

Software Architecture Patterns