레이어드 아키텍처

💡레이어드 아키텍처

애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조를 의미한다. 레이어드 아키텍처는 어떻게 설계하느냐에 따라 용어와 계층의 수가 달라진다.

💡프레젠테이션 계층

• 애플리케이션의 최상단 계층으로, 클라이언트의 요청을 해석하고 응답하는 접점 역할
• UI나 API를 제공
• 프레젠테이션 계층은 별도의 비즈니스 로직을 포함하고 있지 않으므로 비즈니스 계층으로 요청을 위임하고 받은 결과를 응답하는 역할만 수행한다
• 상황에 따라 유저 인터페이스(UI) 계층이라고도 한다
• 클라이언트로부터 데이터와 함께 요청을 받고 처리 결과를 응답으로 전달하는 역할

💡비즈니스 계층

• 애플리케이션이 제공하는 기능을 정의하고 세부 작업을 수행하는 도메인 객체를 통해 업무를 위임하는 역할을 수행한다
• DDD(Domain-Driven Design) 기반의 아키텍처에서는 비즈니스 로직에 도메인이 포함되기도 하고, 별도로 도메인 계층을 두기도 한다.
• 비즈니스 로직은 도메인 계층에서 담당하는 것이 일반적임
• 상황에 따라 서비스 계층이라고도 한다
• 핵심 비즈니스 로직을 구현하는 영역
• 트랜잭션 처리나 유효성 검사 등의 작업도 수행

💡데이터 접근 계층

• 데이터베이스에 접근하는 일련의 작업을 수행한다
• 상황에 따라 영속 계층이라고도 한다

💡레이어드 아키텍처 기반 설계 특징

• 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받는다
• 각 레이어는 관심사에 따라 묶여 있으며, 다른 레이어의 역할을 침범하지 않는다.
  • 각 컴포넌트의 역할이 명확하므로 코드의 가독성과 기능 구현에 유리하다
  • 코드의 확정성도 좋아진다
•  각 레이어가 독립적으로 작성되면 다른 레이어와의 의존성을 낮춰 단위 테스트에 용이하다

💡스프링 MVC

• 스프링 부트는 별도의 설정 없이 spring-boot-starter-web의 의존성을 사용할 때, 기본적으로 스프링 MVC 레이어드 아키텍처를 띠게 된다.
• 스프링 MVC는 Model-View-Controller의 구조로 View와 Controller는 프레젠테이션 계층 영역이며, Model은 비즈니스와 데이터 접근 계층의 영역으로 구분할 수 있다
• 스프링에서 JPA를 사용하면 @Entity를 정의한 클래스가 도메인 객체가 되며, 이곳에서 비즈니스 로직을 설계하면 좋다. 다만 서비스 레이어에서 비즈니스 로직을 담당하는 경우도 있으므로 이러한 역할과 책임을 잘 구분해서 설계해야 한다

 

참고

도서-스프링부트 핵심 가이드