트랜잭션 스크립트 패턴(Transaction Script Pattern)
트랜잭션 스크립트 패턴 개념
엔티티에는 비즈니스 로직이 거의 없고, 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 구조로 작성하는 디자인 패턴이다. 하나의 트랜잭션으로 구성된 로직을 단일 함수 혹은 단일 스크립트에서 처리하는 구조이다. 절차식 프로그래밍이나 데이터베이스 중심 아키텍처와 방식과 동일한 로직 흐름으로 작성한다.
@Transactional
public void cancelOrder(Long orderId) {
// 주문 엔티티 조회
Order order = orderRepostiory.findOne(orderId);
// 주문 취소
if (delivery.getStatus() == DeliveryStatus.COMP) {
throw new IllegalStateException("이미 배송된 상품은 취소가 불가능합니다.");
}
order.changeStatus(OrderStatus.CANCEL);
for (OrderItem orderItem : order.getOrderItems()) {
int stock = orderItem.getStock();
orderItem.changeStock(stock + order.getAmount());
orderItemRepository.update(orderItem.getId());
}
}
Java
복사
이와 같이 서비스에 비즈니스 로직을 모아두고, 엔티티는 자료구조처럼 사용하여 접근자(getter)나 수정자(setter) 정도만 제공하는 방식이다.
트랜잭션 스크립트 패턴 장단점
트랜잭션 스크립트 방식의 최대 장점은 구현이 쉽다는 것이다. ASP.NET이나 JSP 등이 프로그래밍 언어에 기반하고 있는 스크립트 언어임에도 사람들이 프로그래밍 언어보다 쉽다고 느끼는 이유가 구현이 단순하고 쉽기 때문이다. 또한 모듈화를 잘 해둔다면 효율성 좋은 코드를 작성할 수 있다.
하지만 트랜잭션 스크립트 패턴으로 구성된 애플리케이션은 비즈니스 로직이 복잡해질수록 코드가 난잡해진다. 또한 트랜잭션 스크립트 패턴은 도메인에 대한 분석과 설계 개념이 약할 수 밖에 없는데, 때문에 중복된 코드가 자주 발생하게 된다.
도메인 모델 패턴(Design Model Pattern)
도메인 모델 패턴 개념
주요 비즈니스 로직 대부분이 엔티티 내부에 존재하여, 서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 구조로 작성하는 디자인 패턴이다. 엔티티를 활용하여 객체 지향의 특성을 적극 활용하는 형태로 코드를 작성한다.
// OrderItem 클래스
@Entity
public class OrderItem {
...
public static OrderItem createOrderItem(Item item, int orderPrice, int count) {
OrderItem orderItem = new OrderItem(item, orderPrice, count);
this.item.removeStock(count);
return orderItem;
}
public void cancel() {
getItem().addStock(count);
}
}
// 주문 서비스의 주문 취소 메서드
@Transactional
public void cancelOrder(Long orderId) {
// 주문 엔티티 조회
Order order = orderRepostiory.findOne(orderId);
// 주문 취소
order.cancel();
}
Java
복사
이처럼 엔티티를 객체처럼 사용하기 때문에 비즈니스 로직이 거의 엔티티에 있어, 서비스는 엔티티를 호출하는 정도의 얇은 비즈니스 로직만을 가지는 방식이다.
추가적으로 도메인 모델이란 도메인을 모든 사람이 동일한 관점에서 이해할 수 있고 공유할 수 있도록 단순화 시킨 것을 말하는데, 도메인의 핵심을 간략하게 단순화해서 표현할 수 있는 모든 것이 도메인 모델이다. 이러한 도메인 모델을 중점으로 생각하여, 관심사(aggregate) 분리하며 그 외의 추가적인 여러 개념들을 통해 도메인 중심으로 설계하는 방식을 DDD(Domain Driven Design)이라 한다.
도메인 모델 패턴 장단점
도메인 모델 패턴은 객체 지향에 기반하여 코드를 작성하기 때문에, 재사용성과 확장성, 유지보수의 편리함, 코드의 응집도 등 객체지향의 장점을 그대로 가질 수 있다. 또한 일단 도메인 모델을 한 번 구축하고 나면, 이후 비슷한 도메인 모델을 구축할 때 이미 작성된 도메인 모델을 재사용할 수 있다. 추가적으로 상속이나 인터페이스, 컴포넌트 개념을 바탕으로 도메인 모델을 개발한다면, 객체지향만큼이나 무한한 확장성을 가질 수도 있다.
하지만 이러한 도메인 모델 패턴을 구축하기 위해서는 객체를 판별과 객체 간의 관계 정립, 객체와 데이터베이스의 매핑, 객체지향적인 코드 스타일 작성 등 많은 고민과 노력을 해야한다. 이는 이론과 경험을 함께 겸비하지 않으면, 쉽게 구축하기 어렵기 때문에 도메인 모델에 능숙한 개발자가 팀에 없다면 도메인 모델을 구축하는 것 자체가 힘들어질 수 있다.
