안녕하세요.
디자인 패턴에 대해서 공부해보도록 하겠습니다.
이번에 학습해볼 디자인 패턴은 트랜잭션 스크립트 패턴(Tansaction Script) 입니다.
가장 최근 프로젝트에 활용한 패턴으로, 이번 학습은 주문 예약 서비스를 예시로 진행해보도록 하겠습니다.
Tansaction Script 패턴이란?
Transaction Script 패턴은 마틴 파울러(Martin Fowler)가
소개한 아키텍처 패턴 중 하나로, 하나의 비즈니스 요청을 처리하는 절차적(procedural) 코드로 비즈니스 로직을 구현하는 방법입니다.
이 포스트에서는 Transaction Script 패턴의 개요와 간단한 패키지 구조, 장단점까지 소개하겠습니다.
Transaction Script 패턴 개요
Transaction Script 패턴은 요청 하나당 독립적인 절차적 코드로 로직을 구현하며, 주로 간단한 비즈니스 로직을 가진 애플리케이션에서 사용됩니다.
특징은 다음과 같습니다.
- 단순한 절차적 흐름으로 로직이 직관적임
- 하나의 트랜잭션을 하나의 메서드로 처리
- 객체 모델 설계가 거의 필요하지 않음
대표적으로 간단한 CRUD 기반의 애플리케이션이나 비즈니스 로직이 복잡하지 않은 서비스에서 자주 사용됩니다.
Transaction Script 패턴 패키지 구조 예시
Java 21과 Spring Boot 환경에서 간단한 구조 예시를 살펴봅시다.
src/main/java/com/example
├── transaction
│ ├── OrderTransaction.java // 주문 트랜잭션 스크립트
│ └── PaymentTransaction.java // 결제 트랜잭션 스크립트
├── controller
│ └── OrderController.java
├── repository
│ └── OrderRepository.java
├── domain
│ └── Order.java
└── Application.javatransaction패키지 내에 트랜잭션 단위의 비즈니스 로직을 담습니다.- 복잡한 객체 지향적 설계보다는 절차적 코드 중심으로 구성됩니다.
Transaction Script 코드 예시
간단한 주문 처리를 Transaction Script 방식으로 구현한 예제입니다.
OrderTransaction.java
@Service
public class OrderTransaction {
private final OrderRepository orderRepository;
public OrderTransaction(OrderRepository orderRepository) {
this.orderRepository = orderRepository;
}
@Transactional
public void reserveOrder(Long productId, int quantity) {
Order order = orderRepository.findByProductIdForUpdate(productId)
.orElseThrow(() -> new RuntimeException("존재하지 않는 상품입니다."));
if (order.getReservedQuantity() + quantity > order.getTotalQuantity()) {
throw new IllegalStateException("재고가 부족합니다.");
}
order.setReservedQuantity(order.getReservedQuantity() + quantity);
orderRepository.save(order);
}
}위와 같이 트랜잭션 범위 안에서 비즈니스 로직을 순차적으로 처리합니다.
Transaction Script 패턴 장단점
| 장점 ✅ | 단점 ❌ |
|---|---|
| 코드가 직관적이고 이해하기 쉽다. | 복잡한 비즈니스 로직에 적합하지 않다. |
| 빠르게 구현하고 프로토타입에 적합하다. | 로직 중복이 발생하기 쉽다. |
| 유지보수와 디버깅이 쉽다. | 확장성 및 코드 재사용성이 떨어진다. |
Transaction Script 패턴 사용 시점
✅ 적합한 상황
- 간단한 CRUD 기반의 애플리케이션
- 빠르게 프로토타입 또는 MVP를 개발할 때
- 비즈니스 로직이 간단하고 명확할 때
🚨 적합하지 않은 상황
- 복잡한 도메인 로직이나 객체 지향적인 설계가 필요한 경우
- 비즈니스 로직이 자주 변경되고 확장성이 중요한 시스템
이런 경우엔 Domain Model이나 Service Layer 등 다른 설계 패턴이 더 적합합니다.
마무리
Transaction Script 패턴은 복잡하지 않은 비즈니스 로직을 빠르게 구현할 때 매우 유용한 패턴입니다.
하지만 애플리케이션 규모가 커지고 도메인이 복잡해질 경우 다른 아키텍처 패턴으로 전환하는 것을 고려해야 합니다. 상황에 맞는 적절한 패턴을 선택해 유지보수하기 좋은 애플리케이션을 만들어보시길 바랍니다.
감사합니다.
