[KSUG Spring Boot Study] 레이어드 아키텍처

레이어드 아키텍처

• 애플리케이션의 컴포넌트르 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조를 의미한다.
• 여러 방면에서 쓰이는 개념이며, 어떻게 설계하느냐에 따라 용어와 계층의 수가 달라진다

3 계층 또는 4계층 구성을 의미한다.

• 이 차이는 인프라(DB)레이어의 추가 여부로 결정된다.

레이어드 아키텍처

 

프레젠테이션 계층

• 애플리케이션의 최상단 계층이며 HTTP 요청/응답을 처리
• 사용자 입력 받기, API 라우팅 역할
• 별도의 비즈니스 로직을 포함하지 있지 않으므로 비즈니스 계층으로 요청을 위임하고 받은 결과를 응답하는 역할만 수행
• @RestController, @Controller

@GetMapping("/users")
public ResponseEntity<?> getUsers() {
    return ResponseEntity.ok(userService.getAllUsers());
}

비즈니스 계층

• 애플리케이션이 제공하는 기능을 정의하고 세부 작업을 수행하는 도메인 객체를 통해 업무를 위임하는 역할을 수행
• DDD(Domain-Driven Design) 기반의 아키텍처는 로직에 도메인이 포함되기도 하고, 별도로 도메인 계층을 두기도 한다.
• 트랜잭션 처리, 여러 Repository 조합
• 도메인 로직을 호출하고 조합한다.

public List<User> getAllUsers() {
    return userRepository.findAll();
}

데이터 접근 계층

• 하나의 애플리케이션에도 적용되지만 애플리케이션 간의 관계를 설명하는 데도 사용

특징

• 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받는다.
• 각 레이어는 관심사에 묶여 있으며, 다른 레이어의 역할을 침범하지 않는다.
  • 각 컴포넌트의 역할이 명확하므로 코드의 가독성과 기능 구현에 유리
  • 코드의 확장성 좋아짐
• 각 레이어가 독립적으로 작성되면 다른 레이어와의 의존성을 낮춰 단위 테스트에 용이
• 실제 DB에 접근해서 CRUD 수행
• JPA, MyBatis 등 사용, @Repository

public interface UserRepository extends JpaRepository<User, Long> {
	
}

 

Domain(도메인 객체 계층)

• Entity, VO, DTO 같은 비즈니스 데이터를 표현
• JPA의 @Entity, Lombok의 @Data 등이 주료 사용

@Entity
public class User {
    @Id
    private Long id;
    private String name;
}

 

spring-boot-starter-web의 의존성을 사용할 때는 기본적으로 스프링 MVC 구조를 띠게 된다.