[Spring] 3 Layer Architecture | Spring 3 Layer

 

 

 

✔  3 Layer Architecture란?

 

서버를 개발 관점에서 각 계층별로 역할을 분리하는 개념입니다.

 

 

 

 

 

 

 

 

1. Presentation Layer, Controller

• 역할: 사용자가 입력한 데이터의 형식이나 간단한 유효성 검사를 수행합니다. 예를 들어, 입력 필드가 빈 값인지, 숫자 필드에 숫자가 들어왔는지, 이메일 형식이 올바른지 등을 검증합니다.
• 쉬운설명: 사용자가 입력한 요청이 유효한 요청인지 검사하고 필터링하는 역할을 합니다. 더하여, 사용자에게 요청을 받고, 데이터를 전달하는 역할을 합니다.
• 구성요소: Spring MVC의 @Controller 혹은 @RestController
• 예시

public class UserDTO {
    @NotNull
    @Size(min = 2, max = 30)
    private String name;

    @NotNull
    @Email
    private String email;

    // getters and setters
}

@RestController
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;
	
    @PostMapping("/user")
    public String createUser(@Valid @ModelAttribute("user") UserDTO userDTO, BindingResult result) {
        if (result.hasErrors()) {
            return "errorPage";
        }
        userService.createUser(userDTO);
        return "successPage";
    }
}

 

 

 

 

2. Service Layer, Service

• 역할: 비즈니스 로직을 처리하는 핵심 레이어입니다. Presentation Layer와 Data Access Layer 사이에서 중간 역할을 합니다. Presentation Layer의 요청을 받아 필요한 데이터를 가공하거나 로직을 실행하여 결과를 반환합니다.
• 쉬운설명: 사용자가 요청한 요구사항을 실질적으로 처리하는 역할을 합니다.
• 구성요소: @Service 어노테이션으로 표시된 클래스
• 예시

@Service
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;

    public void createUser(UserDTO userDTO) {
        if (userRepository.existsByEmail(userDTO.getEmail())) {
            throw new IllegalArgumentException("Email already in use.");
        }
        // Further business logic
        User user = new User(userDTO.getName(), userDTO.getEmail());
        userRepository.save(user);
    }
}

 

 

 

 

3. Data Access Layer, Repository

• 역할: 데이터베이스와 상호작용하며, 데이터를 저장, 검색, 업데이트, 삭제하는 역할을 합니다. 비즈니스 로직에서 데이터를 필요로 할 때 이 레이어를 통해 데이터를 처리합니다.
• 쉬운설명: 스프링에서 데이터베이스의 데이터를 처리하는 역할을 합니다.
• 구성요소: @Repository 어노테이션으로 표시된 클래스들이 여기에 속하며, JPA, Hibernate, MyBatis와 같은 ORM(Object-Relaional Mapping) 프레임워크를 사용해 데이터베이스와 상호작용합니다. 그리고 entity인데, 데이터베이스 테이블과 매핑되는 도메인 객체로, 데이터베이스에서 가져오거나 저장할 데이터를 캡슐화합니다.
• 예시

@Repository
@RequiredArgsConstructor
public class UserService {

    private final JdbcTemplate jdbcTemplate;

    public Optional<User> existsByEmail(UserDTO userDTO) {
        List<Manager> result = jdbcTemplate.query("SELECT * FROM user WHERE id = ?", rowMapper(), userDTO.getUserId());
        return result.stream().findFirst();
    }
}

 

 

 

 

 

 

✔ 3 Layer Architecture 사용 이유

 

 

 

1. 책임의 분리 (Separation of Concerns)

• 설명: 세가지 계층으로 애플리케이션을 나눔으로써 각 계층이 특정 역할만을 수행하도록 만듭니다. 이로 인해 코드의 역할이 명확해지고 각 계층이 자신의 책임에 집중할 수 있게 됩니다.
• 효과: 각 계층이 독립적으로 변화할 수 있어, 한 계층의 변경이 다른 계층이 미치는 영향을 최소화할 수 있습니다. 예를 들어, 데이터베이스의 구조가 변경되어도 Controller에는 영향을 미치지 않도록 설계할 수 있습니다.

 

2. 유지보수성 (Maintainability)

• 설명: 코드의 역할이 명확히 분리되어 있기 때문에 특정 기능을 수정하거나 확장할 때 관련된 계층만 수정하면 됩니다. 이로 인해 코드의 복잡성이 줄어들고 유지보수가 쉬워집니다.
• 효과: 예를 들어, 비즈니스 로직이 변경되면 Service에서만 수정하면 되고, Controller나 Repository는 건드릴 필요가 없습니다. 이는 유지보수 시 버그 발생 가능성을 줄이고, 작업 시간을 단축시킵니다.

 

3. 재사용성 (Reusability)

• 설명: 특정 계층의 코드가 다른 애플리케이션이나 모듈에서 재사용될 수 있습니다. 예를 들어, 동일한 비즈니스 로직이 여러 애플리케이션에서 사용된다면, Service의 코드를 재사용할 수 있습니다.
• 효과: 재사용성을 높임으로써 개발 속도를 향상시키고 중복된 코드 작성에 따른 실수를 줄일 수 있습니다. 또한 재사용 가능한 코드 모듈을 만들어 테스트와 유지보수에 용이하게 합니다.

 

4. 테스트 용이성 (Testability)

• 설명: 각 계층이 독립적이기 때문에 개별 계층을 쉽게 테스트할 수 있습니다. Service나 Repository를 가각 단위 테스트하거나 Controller를 통합 테스트로 테스트할 수 있습니다.
• 효과: 단위 테스트를 통해 개별 모듈의 기능을 철저히 검증할 수 있으며, 계층별로 발생할 수 있는 버그를 조기에 발견하여 수정할 수 있습니다. 이는 시스템의 안정성과 품질을 높이는 데 기여합니다.

 

5. 확장성 (Scalability)

• 설명: 애플리케이션이 확장될 때, 각 계층이 독립적으로 확장 가능하도록 도와줍니다. 예를 들어, 트래픽이 증가할 때 Controller와 Service를 각각 독립적으로 확장하여 부하를 분산시킬 수 있습니다.
• 효과: 계층별로 확장이 가능하기 때문에 특정 기능이나 모듈만 성능 개선이 필요할 때에도 전체 시스템에 영향을 주지 않고 개선할 수 있습니다.

 

6. 보안성 (Security)

• 설명: Controller에서 사용자로부터 입력된 데이터를 Service로 전달하기 전에 유효성 검사를 할 수 있으며, Service에서 비즈니스 로직을 통해 다시 한 번 검증하여 안전한 데이터만 Repository로 전달할 수 있습니다.
• 효과: 보안적인 측면에서 계층별로 데이터를 검증하고 관리할 수 있어, 악의적인 입력이나 잘못된 데이터가 시스템 깊숙이 침투하는 것을 방지할 수 있습니다.