노드 심화_5

계층형 아키텍처 패턴 (Layered Architecture Pattern)

계층을 분리해서 관리하는 아키텍처 패턴이고, 현재 가장 흔하게 사용되고 있는 아키텍처 패턴

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

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

  • 관심사를 분리하여 현재 구현하려하는 코드를 명확하게 인지
  • 각 계층별로 의존성이 낮아 모듈을 교체하더라도 코드 수정이 용이
  • 각 계층별로 단위 테스트를 작성할 수 있어 테스트 코드를 조금 더 용이하게 구성

• 상위 계층은 하위 계층을 사용할 수 있지만, 하위 계층은 자신의 상위 계층에 누가 있는지 알 수 없고, 사용할 수 조차 없도록 구성해야 함

  => 예를 들어 데이터 엑세스 계층 (Data Access Layer)은 비즈니스 로직 계층 (Business Logic Layer)에 어떤 코드들이 있는지 알 수 조차 없고, 사용하면 안된다.

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

저희가 알아볼 아키텍처 패턴은 **3계층 아키텍처(3-Layered Architecture)**입니다.

3계층 아키텍처에서 구성되는 각각의 계층(Layer)는 아래와 같습니다.

• 프레젠테이션 계층 (Presentation Layer)
• 비즈니스 로직 계층 (Business Logic Layer)
• 데이터 엑세스 계층 (Data Access Layer)

3계층 아키텍처 (3-Layered Architecture)

• 3-Layered Architecture 처리과정을 이용해서 구현

  1. Controller : 어플리케이션의 가장 바깥 부분, 요청/응답을 처리
     • 클라이언트의 요청을 처리 한 후 서버에서 처리된 결과를 반환해주는 역할
  2. Service : 어플리케이션의 중간 부분, 실제 중요한 작동이 많이 일어나는 부분
     • 아키텍처의 가장 핵심적인 비즈니스 로직이 수행되는 부분
  3. Repository : 어플리케이션의 가장 안쪽 부분, DB와 맞닿아 있음.
     • 실제 데이터베이스의 데이터를 사용하는 계층

• 3-Layered Architecture에서는 아래의 플로우를 기반으로 로직이 수행

  1. 클라이언트(Client)가 요청(Request)을 보냅니다.

  2. 요청(Request)을 URL에 알맞은 컨트롤러(Controller)가 수신 받습니다.

  3. 컨트롤러(Controller)는 넘어온 요청을 처리하기 위해 서비스(Service)를 호출합니다.

  4. 서비스(Service)는 필요한 데이터를 가져오기위해 저장소(Repository)에게 데이터를 요청합니다.

  5. 서비스(Service)는 저장소(Repository)에서 가져온 데이터를 가공하여 컨트롤러(Controller)에게 데이터를 넘깁니다.

  6. 컨트롤러(Controller)는 서비스(Service)의 결과물(Response)을 클라이언트(Client)에게 전달해줍니다.

1. Controller

- 클라이언트의 요청을 받음
- 요청에 대한 처리는 서비스에게 전담
- 클라이언트에게 응답

2. Service
   

• 사용자의 요구사항을 처리 ('비즈니스 로직') 하는 실세 중에 실세!!!
  • 현업에서는 서비스 코드가 계속 비대해짐
• DB 정보가 필요할 때는 Repository 에게 요청
  

3. Repository
   

• DB 관리 (연결, 해제, 자원 관리)
• DB CRUD 작업 처리

4. 전체 로직