spring 과제

[TIL] Spring 계층 구조와 비즈니스 로직 분리의 근거

2026-04-20 | Backend Development

1. 과제 정리 

Spring Boot 프로젝트에서 Entity, DTO, Controller, Repository, Service로 계층을 나누는 이유와, 특히 Controller에 집중되어 있던 로직을 Service로 왜 분리해야 할까?

2. 문제 상황: Controller에 비즈니스 로직이 있는 경우

기존 OrderController 코드에서는 ProductRepository와 OrderRepository를 직접 의존하며 DB 조회 및 주문 생성 로직을 수행

• 단일 책임 원칙(SRP) 위반: Controller는 클라이언트의 요청을 받고 응답하는 역할에 집중해야 하지만, 데이터 검증 및 비즈니스 흐름까지 제어
• 트랜잭션 관리의 한계: @Transactional이 Controller에 붙어 있어 계층 간의 경계가 모호해진다.

3. 계층별 역할(Layered Architecture)

계층(Layer)	주요 역할
Entity	실제 DB 테이블과 매핑되는 객체, 핵심 비즈니스 도메인 모델
DTO	계층 간 데이터 전송을 위한 객체 (Request/Response 분리)
Controller	HTTP 요청 매핑, 파라미터 검증(@Valid), 응답 반환
Service	비즈니스 로직 수행, 트랜잭션 단위 관리, 다수의 Repository 조율
Repository	DB 접근 로직 (Spring Data JPA 활용)

4. 로직 분리의 기술적 근거 (Service 계층의 필요성)

① 재사용성 (Reusability)
주문 생성 로직이 Controller에 있으면, 다른 서비스(예: 관리자 API, 예약 시스템)에서 동일한 주문 로직이 필요할 때 코드를 복사해야 합니다. Service로 분리하면 다른 클래스에서 orderService.createOrder()를 주입받아 바로 사용할 수 있다.

② 유지보수성 (Maintainability)
DB 구조가 바뀌거나 주문 정책(예: 할인 적용 등)이 변경될 때 Controller를 수정할 필요가 없다. 오직 Service 계층만 수정하면 되므로 변화에 유연합니다.

③ 트랜잭션 원자성 (Atomicity)
주문 생성 시 재고 감소, 포인트 적립 등 여러 DB 작업이 묶여야 할 때, @Transactional을 Service 메서드에 선언함으로써 하나의 작업 단위(Unit of Work)로 안전하게 관리할 수 있다. 

5.정리

단순한 CRUD 프로젝트에서는 Controller에 로직을 다 넣어도 동작에는 문제가 없다.
하지만 확장을  위해서는 각 객체의  명확히 분리하는 것이 핵심이다.