얼음꽃의 일지

계층형 아키텍처 패턴 본문

항해 일지

계층형 아키텍처 패턴

얼음꽃 2022. 12. 1. 09:29
728x90

아키텍처 패턴이란?

- 소프트웨어의 구조를 구성하기 위한 가장 기본적인 토대를 제시

- 각각의 시스템들과 그 역할이 정의되어 있고, 여러 시스템 상이의 관계와 규칙 등이 포함되어 있음

- 검증된 구조로 개발을 진행하기 때문에 안정적인 개발 가능

- 도메인이 복잡할수록 모델이나 코드를 더 쉽게 변경할 수 있는 측면에서 큰 이익

 

대표적인 아키텍처 패턴

- 저장소 패턴(Repository Pattern) : 영속적인 저장소에 대한 추상화

- 서비스 계층 패턴(Service Layer Pattern) : 유스 케이스의 시작과 끝을 명확하게 정의하기 위한 패턴

- 작업 단위 패턴(Unit Of Work Pattern) : 원자적 연산을 제공

- 애그리게이트 패턴(Aggregate Pattern) : 데이터 정합성을 강화하기 위한 패턴

- 계층형 패턴(Layered Architecture Pattern) : 계층을 분리해서 관리하는 아키텍처 패턴, 현재 가장 흔히 사용

 

계층형 아키텍처 패턴을 더 자세히 보자!

- 단순하고 대중적이면서 비용도 적게 들어 모든 어플리케이션의 표준 아키텍처

- 계층을 분리해서 유지하고, 각 계층이 자신의 바로 아래 계층에만 의존하게 만드는 것이 목표

- 계층화의 핵심은 각 계층의 응집도는 높으면서, 다른 계층과는 낮은 결합도를 가지고 있어야함

- 상위 계층은 하위 계층을 사용할 수 있지만, 하위 계층은 자신의 상위 계층에 누가 있는지 알 수 없고, 사용할 수 조차 없음

 

일반적으로 계층형 아키텍처 패턴의 경우, 규모가 작은 어플리케이션의 경우 3개, 크고 복잡한 경우는 그 이상의 계층으로 구성

 

계층형 아키텍처 패턴의 장점

- 관심사를 분리하여 현채 구현하려하는 코드를 명확하게 인지

- 각 계층별로 의존성이 낮아 모듈을 교체하더라도 코드 수정이 용이

- 각 계층별로 단위 테스트를 작성할 수 있어 테스트 코드를 조금 더 용이하게 구성

 

3계층 아키텍처로 알아보자!!

 

3계층을 구성하는 각각의 계층

- 프레젠테이션 계층(Presentation Layer)

- 비즈니스 로직 계층(Business Logic Layer)

- 데이터 엑세스 계층(Data Access Layer)

 

3계층이 처리하는 3가지의 과정

1. Controller : 어플리케이션의 가장 바깥 부분, 요청/응답을 처리함

- 클라이언트의 요청을 처리 한 후 서버에서 처리된 결과를 반환해주는 역할을 함

2. Service : 어플리케이션의 중간 부분, 실제 중요한 작동이 많이 일어나는 부분

- 아키텍처의 가장 핵심적인 비즈니스 로직이 수행되는 부분

- 프레젠테이션 계층과 데이터 엑세스 계층 사이에서 중간 다리 역할을 하며 서로 다른 두 계층이 직접 통신하지 않게 만듦

 

장점

- 저장소에게 얻을 필요가 있는 데이터가 무엇인지 이해 가능

- 어떤 사전 검사와 현재 상태 검증을 필수적으로 해야하는 것을 이해 가능

- 어떤 내용을 저장해야 하는지 이해 가능

- 비즈니스 로직을 API 뒤에 감췄기 때문에 서비스 계층의 코드를 자유롭게 리팩터링 가능

- 저장소 패턴 및 가짜 저장소와 조합하면 높은 수준의 테스트를 작성

 

단점

- 서비스 계층 또한 다른 추상화 계층에 불과

- 서비스 계층에 너무 많은 기능을 넣으면 빈약한 도메인 모델과 같은 안티 패턴이 생길 수 있음

3. Repository : 어플리케이션의 가장 안쪽 부분, DB와 맞닿아 있음

- 실제 데이터베이스의 데이터를 사용하는 계층

- 어플리케이션의 다른 계층에서는 저장소의 세부 사항이 어떤 방식으로 구현되어 있더라도 영향을 받지 않음

 

장점

- 저장소 계층을 구현했을 때 데이터를 저장하는 방법을 더 쉽게 변경할 수 있고, 테스트 코드 작성시 가짜 저장소를 제공하기가 더 쉬워짐

- 접근 방식을 바꾸고 싶을 때 외래키나 마이그레이션 등을 염려하지 않고 모델에 반영할 수 있음

- 객체를 테이블에 매핑하는 과정을 원하는 대로 제어할 수 있어서 DB 스키마를 단순화할 수 있음

 

단점

- 저장소 계층이 없더라도 ORM이 어느 정도 모델과 저장소의 결합을 완화시켜줌

- ORM 매핑을 수동으로 하려면 개발 코스트가 더욱 소모

(여기서 설명하는 ORM은 Seqeulize와 같은 라이브러리)

3계층의 플로우

1. 클라이언트가 요청을 보냄

2. 요청을 URL에 알맞는 컨트롤러가 수신

3. 컨트롤러는 넘어온 요청을 처리하기 위해 서비스를 호출

4. 서비스는 필요한 데이터를 가져오기 위해 저장소에게 데이터를 요청

5. 서비스는 저장소에서 가져온 데이터를 가공하여 컨트롤러에게 데이터를 넘김

6. 컨트롤러는 서비스의 결과물을 클라이언트에게 전달

728x90

'항해 일지' 카테고리의 다른 글

WebSocket 과 Socket.io  (0) 2022.12.06
PM2  (0) 2022.12.05
[DB] 트랜잭션의 ACID  (0) 2022.11.29
RDMS 와 NoSQL은 무엇인가?  (0) 2022.11.28
Nginx + https연결 사용법  (0) 2022.11.02