레이어드 아키텍처

프로젝트의 규모가 커질수록 하나의 클래스에 모든 기능을 구현하면 역할이 많아져 유지보수가 어려워진다.

이를 해결하기 위해 레이어드 아키텍처(Layered Architecture)를 적용하여 역할에 따라 클래스를 분리한다.

대표적으로 다음과 같이 3개의 계층으로 나뉘는데, 음식점에 비유하면 이해하기 쉽다.

• Controller = 홀 직원
• Service = 주방
• Repository = 창고

Controller (홀)

홀 직원은 손님의 주문을 받고 음식을 전달한다.

직접 요리를 하거나 식재료를 꺼내오지 않고, 주문을 주방에 전달하고 완성된 음식을 손님에게 가져다준다.

즉, 사용자와 소통하는 역할을 담당한다.

Service (주방)

주방은 홀에서 전달받은 주문을 실제로 처리한다.

필요한 재료를 창고에서 가져와 요리를 만든 뒤, 완성된 음식을 홀로 전달한다.

즉, 프로그램의 핵심 로직을 수행하는 역할이다.

Repository (창고)

창고는 식재료를 보관하는 곳이다.

요리를 하지는 않고, 필요한 재료를 저장하고 꺼내주는 역할만 담당한다.

즉, 데이터를 저장하고 조회하는 역할을 수행한다.

계층은 순서대로만 호출한다

각 계층은 자신의 바로 아래 계층과만 통신해야 한다.

Controller
    ↓
Service
    ↓
Repository

 

예를 들어 데이터를 조회할 때도

Controller → Service → Repository

 

순서로 요청하고,

조회 결과도

Repository → Service → Controller

 

순서로 다시 전달된다.

Repository가 Controller에 직접 결과를 전달하는 구조는 사용하지 않는다.

창고 직원이 손님에게 직접 음식을 전달하지 않고, 반드시 주방을 거쳐 홀 직원에게 전달하는 것과 같은 원리이다.

이처럼 계층 간의 역할과 의존 관계를 지키면 각 계층의 책임이 명확해지고, 유지보수와 확장이 쉬워진다.