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

계층형 아키텍처 패턴(Layered Architecture Pattern)은 계층을 분리해서 관리하는 아키텍처 패턴이고, 현재 가장 흔하게 사용되고 있는 아키텍처 패턴 중 하나입니다.

단순하고 대중적이면서 비용도 적게 들어 모든 어플리케이션의 사실상 표준 아키텍처입니다.

계층형 아키텍처 패턴은 어떤 경우든 계층을 분리해서 유지하고, 각 계층이 자신의 바로 아래 계층에만 의존하게 만드는 것이 목표입니다.

계층화의 핵심은 각 계층은 응집도(Cohesion)가 높으면서, 다른 계층과는 낮은 결합도(Coupling)를 가지고 있어야합니다.

여기서 상위 계층은 하위 계층을 사용할 수 있지만, 하위 계층은 자신의 상위 계층에 누가 있는지 알 수 없고, 사용할 수 조차 없도록 구성해야합니다.

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

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

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

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

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

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

3-Layered Architecture 의 3가지의 처리과정

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

실제 수행 플로우

1. 클라이언트(Client)가 요청(Request)을 보냅니다.
2. 요청(Request)을 URL에 알맞은 컨트롤러(Controller)가 수신 받습니다.
3. 컨트롤러(Controller)는 넘어온 요청을 처리하기 위해 서비스(Service)를 호출합니다.
4. 서비스(Service)는 필요한 데이터를 가져오기위해 저장소(Repository)에게 데이터를 요청합니다.
5. 서비스(Service)는 저장소(Repository)에서 가져온 데이터를 가공하여 컨트롤러(Controller)에게 데이터를 넘깁니다.
6. 컨트롤러(Controller)는 서비스(Service)의 결과물(Response)을 클라이언트(Client)에게 전달해줍니다.