[📕 기초 Spring] 6-1. 레이어드 아키텍처(Layered Architecture)

📕 목차

1. 기존 패턴의 문제점
2. 레이어드 아키텍처(Layered Architecture)
3. 프레젠테이션 계층 (Presentation Layer)
4. 비즈니스 계층 (Business Layer)
5. 데이터 접근 계층 (Data Access Layer)
6. DTO, Model(Entity), DAO

---

1. 기존 패턴의 문제점

• 기존의 MVC 패턴에서 Controller는 역할이 무수히 많다.
  1. 요청에 대한 처리
  2. 예외처리
  3. View Template 응답 or Data 응답
  4. 비지니스 로직 처리
  5. DB 상호작용
• 문제점
  • Controller에서 요청에 대한 모든 처리를 수행한다. 즉, 책임이 너무 많다.
  • 기능 추가, 수정, 삭제 등의 유지보수가 힘들어진다.
  • 코드의 재사용성이 떨어진다. 메서드로 분리하여도 메서드를 호출하는 중복 코드가 발생한다.

---

2. 레이어드 아키텍처(Layered Architecture)

• 소프트웨어 시스템을 기능적으로 구분된 계층(Layer)으로 나누어 설계하는 아키텍처 스타일이다.
• 각 계층은 특정한 책임(역할)을 가지고 있다.
• 계층 간에는 명확한 역할 분담이 이루어져 코드의 재사용성, 유지보수성, 확장성을 높이는 데 도움을 준다.

 

레이어드 아키텍처 구조

• 프레젠테이션 계층 (Presentation Layer)
• 비즈니스 계층 (Business Layer)
• 데이터 접근 계층 (Data Access Layer)

---

3. 프레젠테이션 계층 (Presentation Layer)

프레젠테이션 계층 (Presentation Layer)

• 사용자의 요청 (HTTP 요청)을 받고 응답한다.
• 화면을 응답하거나 데이터를 응답하는 API를 정의한다.
• 요청 데이터를 검증하고 DTO로 변환한 뒤, 비즈니스 계층에 전달한다.
• 예: @RestController, @GetMapping, @PostMapping

@GetMapping("/users/{id}")
public UserResponse getUser(@PathVariable Long id) {
    return userService.getUserById(id);
}

---

4. 비즈니스 계층 (Business Layer)

비즈니스 계층 (Business Layer)

• 전달받은 요청을 바탕으로 필요한 비즈니스 로직을 수행한다.
• 데이터가 필요하면 Repository Layer에 접근한다.
• 일반적으로 하나의 비지니스 로직은 하나의 트랜잭션으로 동작한다.
• 예: @Service

public UserResponse getUserById(Long id) {
    User user = userRepository.findById(id)
        .orElseThrow(() -> new UserNotFoundException(id));
    return UserResponse.from(user);
}

---

5. 데이터 접근 계층 (Data Access Layer)

• DB와 연동되어 실제 데이터를 관리한다.
• JPA, MyBatis 등 ORM 또는 SQL 매퍼를 사용한다.
• 예: @Repository

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

 

 

* 응답 흐름

• Repository → Service → Controller → Client 순서로 응답이 전달된다.
• 각 계층은 자신보다 하위 계층만 의존하며, 상위 계층은 알지 못한다 (의존성 방향은 단방향이다).

---

6. DTO, Model(Entity), DAO

DTO (Data Transfer Object)

• 데이터 전송을 목적으로 사용하는 객체
• Controller ↔ Service 간 또는 Service ↔ 외부 시스템 간 데이터 전달을 위해 사용된다.
• 주로 UserRequest, UserResponse, ProductDto 등으로 사용됨

public class UserRequest {
    private String name;
    private String email;
}

 

 

Model (Entity)

• 데이터베이스와의 연관을 가진 객체로, 데이터베이스 테이블의 구조를 객체지향적으로 표현한 것이다.
• DB 테이블과 1:1 매핑되며, 비즈니스 로직 또는 상태를 포함할 수 있다.

@Entity
public class User {
    @Id @GeneratedValue
    private Long id;

    private String name;
    private String email;

    public void changeEmail(String newEmail) {
        this.email = newEmail;
    }
}

 

 

DAO (Data Access Object)

• 데이터베이스와의 상호작용을 담당하는 객체
• 데이터베이스에 접근하여 데이터를 조회, 저장, 수정, 삭제하는 등의 작업을 처리하는 역할을 한다.
• 스프링에서는 주로 Repository 패턴을 사용하며, DAO는 전통적인 방식에서 많이 쓰인다.

public class UserDAO {
    private EntityManager entityManager;

    public UserDAO(EntityManager entityManager) {
        this.entityManager = entityManager;
    }

    public void save(User user) {
        entityManager.persist(user);
    }

    public User findById(Long id) {
        return entityManager.find(User.class, id);
    }
}