📚[Backend Development] Java Spring 프레임워크의 계층 - Business Layer(비즈니스 계층)

✅ Business Layer (비즈니스 계층)

• 주요 컴포넌트 : @Service
• 역할 : 애플리케이션의 핵심 비즈니스 로직을 처리합니다.
• 설명 : 사용자의 요청에 대한 실제 작업(e.g, “게시글을 저장한다”, “사용자 등급을 업데이트한다”)을 수행합니다. 여러 데이터 접근 계층의 기능을 조합하여 하나의 트랜잭션으로 묶거나, 복잡한 계산을 처리하는 등 비즈니스의 ‘규칙’과 ‘정책’을 구현하는 부분입니다.

✅ 1. 핵심 비즈니스 로직 (Core Business Logic)

“이 서비스를 무엇 때문에 사용하는가?”라는 질문에 대한 답을 코드로 구현한 것입니다.
즉, 애플리케이션의 존재 이유이자 핵심 기능 그 자체를 의미합니다.

• 개념 : 데이터를 단순히 저장하고 보여주는 것을 넘어, 특정 목적을 위해 데이터를 가공하고 처리하는 모든 과정입니다.
• 예시 (쇼핑몰) :
  • ‘주문 처리’ 로직: 사용자가 ‘주문하기’ 버튼을 누르면, 시스템은 상품의 재고를 확인하고, 사용자의 쿠폰을 적용하여 최종 결제 금액을 계산하고, 사용자의 등급에 따라 포인트를 적립한 후, 배송 정보를 생성합니다. 이 모든 과정의 조합이 바로 ‘주문 처리’라는 하나의 핵심 비즈니스 로직입니다.

✅ 2. 트랜잭션 (Transaction)

서로 관련된 여러 개의 작업을 하나의 묶음으로 처리하는 것을 의미합니다. 이 묶음 안의 작업들은 ‘모두 성공하거나 모두 실패해야’ 합니다 (All or Nothing).

• 개념 : 데이터의 일관성과 무결성을 보장하기 위한 매우 중요한 기능입니다. 중간에 하나의 작업이라도 실패하면, 이전에 성공했던 모든 작업을 원래 상태로 되돌립니다(Rollback).
• 예시 (계좌 이체) :
  • A의 계좌에서 1만 원을 출금하고, B의 계좌에서 1만 원을 입금하는 것은 두 개의 작업입니다.
  • 만약 출금은 성공했는데, 시스템 오류로 입금이 실패하면 돈이 공중으로 사라지게 됩니다.
  • ‘트랜잭션’은 이 두 작업을 하나로 묶어, 입금이 실패하면 성공했던 출금까지 취소시켜 데이터가 틀어지는 것을 막아줍니다. Spring에서는 @Transactional 어노테이션으로 간단하게 적용할 수 있습니다.

✅ 3. 비즈니스의 규칙 (Business Rule)

애플리케이션이 따라야 하는 구체적이고 명확한 조건이나 제약사항을 말합니다.
보통 ‘참/거짓’으로 판별할 수 있는 명제 형태를 띱니다.

• 개념 : 데이터나 프로세스가 유효한 상태를 유지하기 위한 개별적인 검사 항목입니다.
• 예시 (쇼핑몰) :
  • “회원가입 시 비밀번호는 반드시 8자 이상이어야 한다.”
  • “상품의 재고가 0이면 ‘품절’ 상태로 표시해야 한다.”
  • “미성년자는 주류를 구매할 수 없다.”

✅ 4. 비즈니스의 정책 (Business Policy)

여러 비즈니스 규칙들이 모여서 만들어진, 더 넓은 범위의 운영 방침이나 전략을 의미합니다.

• 개념 : 하나의 규칙이라기보다는, 특정 상황에서 비즈니스가 어떻게 운영될지에 대한 전반적인 가이드라인입니다.
• 예시 (쇼핑몰) :
  • “배송비 정책” : “기본 배송비는 3,000원이다(규칙1). 하지만, 5만 원 이상 구매 시 배송비는 무료다(규칙2). 또한, 제주 및 도서 산간 지역은 추가 배송비 5,000원이 붙는다(규칙3).” 이 규칙들의 집합이 ‘배송비 정책’이라는 하나의 정책을 이룹니다.
  • ‘환불 정책’ : “구매 후 7일 이내에만 환불이 가능하다(규칙1). 상품의 포장이 훼손되지 않아야 한다(규칙2).”

✅ Service의 역할은 무엇인가요?

Service의 핵심 역할은 비즈니스 로직을 구현하는 것입니다. Controller로부터 요청을 받아, 데이터를 가공하거나 여러 데이터 소스를 조합하는 등 실제적인 ‘업무’를 처리합니다.

• 비즈니스 로직 중앙화 : 애플리케이션의 핵심 로직을 한 곳에 모아 관리함으로써 코드의 일관성을 유지하고 중복을 방지합니다.
• 트랜잭션 관리 : 여러 데이터베이스 작업을 하나의 단위(트랜잭션)로 묶어 데이터의 일관성을 보장합니다. 예를 들어, 출금과 입금이 모두 성공해야만 계좌이체가 완료되도록 관리합니다.
• Controller와 Repository 분리 : Service는 Controller가 비즈니스 로직을 직접 알지 못하게 하고, Repository가 단순한 데이터 CRUD(생성, 조회, 수정, 삭제)에만 집중하도록 하는 중간 다리 역할을 수행합니다.

✅ Service는 언제 사용하나요?

Controller가 받은 요청을 처리하기 위해 단순한 데이터 전달 이상의 작업이 필요할 때 사용합니다.

• 하나의 기능이 여러 데이터베이스 작업을 필요로 할 때 (e.g, 게시글 작성 시 게시글 저장 후, 사용자 포인트 업데이트)
• 데이터를 가공하거나 비즈니스 규칙을 적용해야할 때 (e.g, 사용자 나이를 계산하거나, 주문 금액에 따라 배송비를 결정할 때)
• 트랜잭션 처리가 필요하여 데이터의 원자성(All or Nothing)을 보장해야 할 때

✅ Service는 어떻게 사용하나요?

@Service 어노테이션을 클래스에 붙여 사용하며, 데이터베이스 접근을 위해 Repository를 주입받아 비즈니스 로직을 구현합니다.

아래는 id로 사용자를 조회하되, 없을 경우 예외를 발생시키는 간단한 Service 예시 코드입니다.

// 이 클래스가 비즈니스 로직을 처리하는 Service임을 선언합니다.
@Service
public class UserService {
    
    // 데이터베이스 접근을 위한 UserRepository를 연결합니다. (의존성 주입)
    private final UserRepository userRepository;
    
    public UserService(UserRepository userRepository) {
        this.userRepository = userRespository;
    }
    
    /**
     * 사용자 ID로 사용자를 조회하는 메서드
     * @Transactional(readOnly = true)는 이 메서드가 데이터베이스를 읽기만 하는
     * 작업이며, 약간의 성능 최적화를 제공합니다.
     */
    @Transactional(readOnly = true)
    public User findUserById(Long id) {
        // Repository를 통해 ID로 사용자를 찾고,
        // 만약 사용자가 없으면 예외를 발생시키는 '비즈니스 로직'을 수행합니다.
        return userRepository.findById(id)
            .orElseThrow(() -> new IllegalArgumentException("해당 사용자가 없습니다. id=" + id));
    }
}

// Controller에서는 이 Service를 주입받아 사용합니다.
@RestController
public class UserController {
    
    private final UserService userService;
    
    public UserController(UserService userService) {
        this.userService = userService;
    }
    
    @GetMapping("/api/users/{id}")
    public User getUserById(@PathVariable Long id) {
        // Controller는 비즈니스 로직을 직접 수행하지 않고 Service의 메서드를 호출합니다.
        return userService.findUserById(id);
    }
}

✅ 1. Business Layer는 언제 사용하나요?

애플리케이션의 핵심 기능을 수행해야 할 때 항상 사용합니다.
Controller로부터 요청을 받아, 단순히 데이터를 전달하는 것을 넘어 데이터를 가공하거나, 비즈니스 규칙을 적용하고, 여러 단계의 작업을 하나의 묶음(트랜잭션)으로 처리해야 할 때 이 계층이 중심적인 역할을 합니다.

✅ 2. Business Layer는 어디서 사용하나요?

애플리케이션 아키텍처에서 Presentation Layer(Controller)와 Data Access Layer(Repositoty) 사이의 중간 계층에 위치합니다.
외부의 요청을 처리하는 부분과 데이터베이스에 직접 접근하는 부분을 분리하여, 그 사이에서 실질적인 업무를 처리하는 ‘두뇌’역할을 담당합니다.

✅ 3. Business Layer는 어떻게 사용하나요?

주로 @Service 어노테이션을 사용하여 클래스를 정의하고, 이 클래스 안에서 비즈니스 로직을 메서드로 구현합니다.

• @Service 클래스는 데이터베이스 접근을 위해 @Repository를 주입(Injection) 받습니다.
• Controller로부터 전달받은 데이터를 사용하여, Repository를 통해 데이터를 조회하거나 저장합니다.
• 데이터를 가공하고, 비즈니스 규칙을 적용하며, @Transactional 어노테이션을 통해 데이터 처리의 일관성을 보장합니다.

✅ 4. Business Layer는 왜 사용하나요?

가장 중요한 이유는 관심사의 분리(Separation of Concerns) 를 통해 얻는 여러 이점 때문입니다.

• 유지보수성 향상 : 비즈니스 정책(e.g, 할인율 변경)이 바뀔 때, 다른 계층은 건드리지 않고 Business Layer의 관련 코드만 수정하면 되므로 관리가 매우 용이합니다.
• 코드 재사용성 증가 : 하나의 비즈니스 로직(e.g, 회원가입)을 만들어주면, 웹 Controller, 모바일 API Controller 등 여러 곳에서 해당 Service를 호출하여 재사용할 수 있습니다.
• 트랜잭션 관리 : 여러 개의 데이터베이스 변경 작업을 하나의 논리적인 단위로 묶어 처리하기에 가장 적합한 위치입니다. 이를 통해 데이터의 정합성을 안전하게 지킬 수 있습니다.
• 테스트 용이성 : 웹 서버나 데이터베이스 없이도 순수 비즈니스 로직 자체의 정확성을 독립적으로 테스트하기 편리합니다.