[항해 14기] 개발일지24 (Layered Architecture Pattern)

Node.js 심화

 

1. Architecture Pattern

1) 정의

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

- 각각의 시스템과 역할이 정해져있고, 해당 시스템들의 관계와 규칙등이 포함

2) 특성

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

- 도메인이 복잡할수록 모델/코드의 관리가 용이

3) 대표적인 종류

- 저장소 패턴 : 모든 데이터가 메모리에 존재하는 것처럼 가정하고, 이를 추상화함

- 서비스 계층 패턴 : usecase의 시작과 끝의 진행과정을 명확하게 정의

- 작업 단위 패턴 : 비즈니스 트랜잭션의 영향받은 개체의 리스트를 관리, 변화 기록(원자적 연산 제공)

- 애그리게이트 패턴 : 데이터의 정합성을 강화

4) 아키택쳐 패턴 도입 전 고민 사항

- 아키택쳐 패턴이 주는 이득을 확인

- 아키택쳐 패턴의 장단점 인지

 

 

 

2. Layered Architecture Pattern

1) 정의

- 가장 대중적이면서 비용이 적음(표준 아키택쳐)

2) 설계 방식

- 계층 끼리 응집도가 높지만 다른 계층과는 결합도가 낮아야함

- 상위 계층은 하위 계층을 사용할 수 있지만 반대는 불가능

- 크게 프레젠테이션 계층/비즈니스로직 계층/데이터액세스계층 으로 구분

3) 장점

- 담당 역할을 분리하여 모듈 단위별 코드의 기능을 명확하게 인지 가능

- 계층별 의존성이 낮아 모듈 교체가 용이

- 계층별 단위 테스트가 용이

4) 구성

- 컨트롤러 : 바깥부분, 클라이언트와 req/res처리

- 서비스 : 중간부분, 핵심적인 로직이 있으며 데이터를 가공해 컨트롤러에 전달

- 저장소 : 안쪽부분, db를 관리함

5) 플로우

- 클라이언트가 요청 -> 요청에 맞는url의 컨트롤러가 수신 -> 서비스 호출 -> 서비스가 저장소 호출 -> 서비스에서 저장소의 데이터를 가공하여 컨트롤러로 넘김 -> 컨트롤러가 클아이언트에게 res

 

 

3. Controller

- 클라이언트 req 수신, req검증, res

- 프레젠테이션 계층

- 예외처리 및 유효성 검증

 

 

 

4. Service

- 프레젠테이션과 데이터 액세스 계층의 중간, 두 계층의 직접적인 통신을 막음

- 핵심적인 비즈니스 로직을 수행

- 비즈니스 로직 계층

- 유스케이스와 워크 플로우를 정의 할 때 유용하며 테스트가 용이

 

 

 

5. Repository

- 데이터 액세스 계층

- DB관련 작업 수행

- 모든 데이터가 존재하는 것처럼 추상화

- 접근방식 변경 시 외래키/마이그레이션 고려없이 모델에 반영 가능

- 매핑과정 제어가 가능해 DB스키마 단순화 가능

- 단위테스트가 용이