12.1 계층형 아키텍처 조립

복잡한 비즈니스 로직을 깔끔하게 유지하기 위해 스프링 애플리케이션은 일반적으로 계층형 아키텍처(Layered Architecture) 를 따릅니다. 각 계층이 명확한 책임을 가질 때 유지보수성과 테스트 용이성이 높아집니다.

1. 전형적인 3계층 구조

1. Presentation Layer (Controller): 외부로부터의 요청을 받고 응답을 반환하는 접점입니다. 데이터의 형식(JSON/XML) 변환과 입력값의 기본 검증(Validation)을 담당합니다.
2. Service Layer (Business Logic): 애플리케이션의 핵심 로직이 위치하는 곳입니다. 트랜잭션의 경계를 설정하고, 여러 Repository를 조합하여 하나의 비즈니스 워크플로우를 완성합니다.
3. Data Access Layer (Repository): 데이터베이스나 파일 시스템 등과의 통신을 담당합니다. JPA Repository 등이 이 계층에 해당합니다.

2. DTO와 Entity의 분리

도메인 모델인 Entity 와 데이터 전송 객체인 DTO 를 엄격히 분리하는 것이 좋습니다.

• Entity: DB 테이블과 매핑되는 핵심 클래스로, 비즈니스 규칙을 내포합니다. 외부로 직접 노출되면 안 됩니다.
• DTO (Data Transfer Object): API의 스펙에 맞게 데이터를 전달하기 위한 객체입니다. 계층 간 이동 시 사용됩니다.

3. 의존성 주입 흐름

graph LR
    Controller --> Service
    Service --> Repository
    Repository --> DB

• 컨트롤러는 서비스에 의존합니다.
• 서비스는 리포지토리에 의존합니다.
• 가급적 인터페이스를 사용하여 유연성을 확보합니다.

4. 실전 코드 구조 예시

@Service
@Transactional
@RequiredArgsConstructor
public class OrderService {
    private final OrderRepository orderRepository;
    private final MemberRepository memberRepository;

    public Long order(Long memberId, String itemName, int count) {
        // 1. 엔티티 조회
        Member member = memberRepository.findById(memberId).get();
        // 2. 비즈니스 로직 실행 및 주문 생성
        Order order = Order.createOrder(member, itemName, count);
        // 3. 주문 저장
        orderRepository.save(order);
        return order.getId();
    }
}

🎯 핵심 요점

• 애플리케이션은 Controller - Service - Repository 계층으로 분리하여 관리합니다.
• 서비스 계층 에서 비즈니스 로직을 처리하고 트랜잭션을 관리합니다.
• Entity 는 내부 DB용으로, DTO 는 외부 통신용으로 분리하여 사용합니다.